@secure-ai/guard 0.2.0 → 0.2.2

package/README.md

@@ -133,7 +133,7 @@ cause in a process already carrying too many.
 ## Also available over MCP
 
 Agents that speak MCP can reach the same controls as tools at
-`https://api.secureai.one/mcp` — `inspect_action`, `check_policy`,
+`https://secureai.one/mcp` — `inspect_action`, `check_policy`,
 `recent_activity`, plus `redact` and `restore`.
 
 Full reference: <https://secureai.one/developers>

package/dist/index.d.ts

@@ -250,7 +250,7 @@ export declare class SecureAI {
      * What to hand the wrapped function.
      *
      * The API omits `input` only on a block, so on any other decision it is
-     * there. The question is what to do if it is not, and the answer is not
+     * there. The question is what to do when it is not, and the answer is not
      * "send what the caller had".
      *
      * On a redact, the caller's input is the one thing that must not go: it
@@ -261,6 +261,25 @@ export declare class SecureAI {
      *
      * On an allow, nothing was rewritten and the caller's own input is the
      * correct thing to pass, so the fallback is right there and stays.
+     *
+     * ── Why this asks which decisions may send, rather than which may not ──
+     *
+     * Two decisions mean "this may go": allow and redact. Every other value,
+     * present or future, means it may not. Asked the other way round — refuse
+     * on block, refuse on approve, send otherwise — a decision added to the
+     * policy later is sent by a client that has never heard of it, and the
+     * agent is told the check passed.
+     *
+     * That is not hypothetical here. It is the bug this library already had:
+     * "approve" was added, `guard` compared against "block" and nothing else,
+     * and an action a policy said must wait for a person went immediately.
+     * The Python comment on that branch still records it. The same shape cost
+     * ten fixes across the Worker, the dashboard and both clients.
+     *
+     * Reachable today? No. The Worker returns 409 rather than a second
+     * "approve" when an approval cannot be redeemed, so the re-check after a
+     * yes comes back allow, redact, or an error. This is the client refusing
+     * to depend on that, across a version boundary it does not control.
      */
     private sendable;
     guard<A, R>(tool: string, fn: (input: A) => Promise<R> | R, opts?: {

package/dist/index.js

@@ -82,7 +82,44 @@ export class SecureAIError extends Error {
         this.code = code;
     }
 }
-const DEFAULT_BASE = "https://api.secureai.one";
+/**
+ * Where the client talks to, when nobody says otherwise.
+ *
+ * This was an api. subdomain in 0.2.0, and that host does not
+ * exist -- it was never created. Nothing caught it: the tests
+ * pass a baseUrl, the typecheck has no opinion about a string, and the
+ * package published cleanly. The first person to install the SDK and follow
+ * the README would have got ENOTFOUND on their first call.
+ *
+ * secureai.one/v1 is the address the docs have always given and it is
+ * proxied to the Worker, so this is the same endpoint the curl examples hit.
+ * Keep the two in step: docs/api.md in the web repo is the other half.
+ */
+const DEFAULT_BASE = "https://secureai.one";
+/**
+ * An approval off the wire, with the one field the wait loop depends on
+ * made a number.
+ *
+ * waitForApproval stops when now is past expiresAt. Handed a body without
+ * one, `Date.now() >= undefined` is a NaN comparison, which is false —
+ * so the loop never stops. Not an error, not a hang anybody can see from
+ * the outside: a guarded call polling a metered API every two seconds for
+ * as long as the process lives.
+ *
+ * The Python client already coerced this, defaulting a missing expiry to 0
+ * and so treating it as already expired. This is the same rule: anything
+ * that is not a finite number means expired, which refuses rather than
+ * waits. Today's Worker always sends one — buildApproval sets it from a
+ * bounded TTL — and the client should not be the reason a change there
+ * becomes an infinite loop in somebody's agent.
+ */
+function toApproval(raw) {
+    const expiresAt = Number(raw?.expiresAt);
+    return {
+        ...raw,
+        expiresAt: Number.isFinite(expiresAt) ? expiresAt : 0,
+    };
+}
 export class SecureAI {
     apiKey;
     baseUrl;
@@ -146,7 +183,7 @@ export class SecureAI {
     /** One held action. */
     async approval(id) {
         const body = await this.request("GET", `/v1/approvals/${encodeURIComponent(id)}`);
-        return body.approval;
+        return toApproval(body.approval);
     }
     /** Everything waiting, for a reviewer's screen. */
     async approvals(opts) {
@@ -157,7 +194,7 @@ export class SecureAI {
             q.set("limit", String(opts.limit));
         const qs = q.toString();
         const body = await this.request("GET", `/v1/approvals${qs ? `?${qs}` : ""}`);
-        return body.approvals;
+        return (body.approvals ?? []).map(toApproval);
     }
     /**
      * Wait for a person to decide.
@@ -235,7 +272,7 @@ export class SecureAI {
      * What to hand the wrapped function.
      *
      * The API omits `input` only on a block, so on any other decision it is
-     * there. The question is what to do if it is not, and the answer is not
+     * there. The question is what to do when it is not, and the answer is not
      * "send what the caller had".
      *
      * On a redact, the caller's input is the one thing that must not go: it
@@ -246,8 +283,32 @@ export class SecureAI {
      *
      * On an allow, nothing was rewritten and the caller's own input is the
      * correct thing to pass, so the fallback is right there and stays.
+     *
+     * ── Why this asks which decisions may send, rather than which may not ──
+     *
+     * Two decisions mean "this may go": allow and redact. Every other value,
+     * present or future, means it may not. Asked the other way round — refuse
+     * on block, refuse on approve, send otherwise — a decision added to the
+     * policy later is sent by a client that has never heard of it, and the
+     * agent is told the check passed.
+     *
+     * That is not hypothetical here. It is the bug this library already had:
+     * "approve" was added, `guard` compared against "block" and nothing else,
+     * and an action a policy said must wait for a person went immediately.
+     * The Python comment on that branch still records it. The same shape cost
+     * ten fixes across the Worker, the dashboard and both clients.
+     *
+     * Reachable today? No. The Worker returns 409 rather than a second
+     * "approve" when an approval cannot be redeemed, so the re-check after a
+     * yes comes back allow, redact, or an error. This is the client refusing
+     * to depend on that, across a version boundary it does not control.
      */
     sendable(tool, verdict, original) {
+        if (verdict.decision !== "allow" && verdict.decision !== "redact") {
+            throw new SecureAIError(`Secure AI answered "${verdict.decision}" for ${tool}, which this ` +
+                `version does not know how to send safely. Nothing was sent. ` +
+                `Upgrade @secure-ai/guard.`, 502, "unknown_decision");
+        }
         if (verdict.input !== undefined)
             return verdict.input;
         if (verdict.decision === "redact") {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@secure-ai/guard",
-  "version": "0.2.0",
+  "version": "0.2.2",
   "description": "Data loss prevention for AI agents. Inspect what an agent is about to do, before it does it.",
   "license": "MIT",
   "type": "module",