@anchrd/intel-api 0.7.0 → 0.9.0

package/dist/tools/tool-servers/tool-servers.js

@@ -0,0 +1,114 @@
+import { serverOf } from "@anchrd/intel-contract";
+import { z } from "zod";
+/**
+ * The portal's own directory tool. It is an ordinary entry in `tools/list`, so it is reached the
+ * same way every other tool is: `tools/call` with the asking user's portal token.
+ *
+ * ⚠️ Its presence in the live list is also the permission check. A deployment whose portal does not
+ * offer it, or a user whose Access policies hide it, gets no server list at all — and therefore
+ * cannot delegate anything. That is deliberate: the alternative would be inventing the server list
+ * out of tool names, which is exactly the guess this module exists to avoid.
+ */
+export const ServerDirectoryTool = "portal_list_servers";
+/**
+ * What the portal answers about one server, read as tolerantly as possible.
+ *
+ * ⚠️ Only the shape is assumed, never the vocabulary. The portal is somebody else's product and its
+ * payload is not part of any contract Intel owns, so every field is optional and the answer is
+ * accepted from `structuredContent`, from `{ servers: [...] }` or from a JSON text block. What
+ * makes a row usable is not that it parsed but that its identifier is confirmed against the live
+ * tool list below.
+ */
+const DirectoryRow = z.looseObject({
+    id: z.string().optional(),
+    name: z.string().optional(),
+    enabled: z.boolean().optional(),
+});
+const DirectoryRows = z.array(DirectoryRow);
+const DirectoryEnvelope = z.looseObject({ servers: DirectoryRows });
+/**
+ * Every place the portal could reasonably have put its list, tried in order. An MCP tool result is
+ * either structured or text, and a server that answers with `{ servers: [...] }` is as likely as
+ * one that answers with a bare array.
+ */
+function rows(answer) {
+    const candidates = [answer.structuredContent];
+    for (const block of answer.content) {
+        if (typeof block === "object" && block !== null && "text" in block) {
+            const text = block.text;
+            if (typeof text !== "string")
+                continue;
+            try {
+                candidates.push(JSON.parse(text));
+            }
+            catch {
+                // A text block that is not JSON is prose, not a directory. Skip it rather than fail: the
+                // portal may well add a human sentence beside the payload.
+            }
+        }
+    }
+    for (const candidate of candidates) {
+        const bare = DirectoryRows.safeParse(candidate);
+        if (bare.success)
+            return bare.data;
+        const wrapped = DirectoryEnvelope.safeParse(candidate);
+        if (wrapped.success)
+            return wrapped.data.servers;
+    }
+    return null;
+}
+/**
+ * ⚠️ The rule itself — longest match against declared handles, never a cut at an underscore — is
+ * `serverOf` in `@anchrd/intel-contract`, because the tools screen has to read a name exactly the
+ * way the delegation does (#212). What stays here is what the rule is USED for: a tool whose prefix
+ * matches no declared handle belongs to no server and can never be delegated, which is what keeps
+ * the portal's own management tools (`portal_list_servers`, `portal_toggle_servers`) out of an
+ * agent's reach — the portal does not list itself as an upstream server.
+ */
+/**
+ * ⚠️ A handle that would carry the portal's OWN tools is never a server anybody can be given.
+ *
+ * The portal does not list itself as an upstream, so in practice `portal` never appears in the
+ * directory — but "in practice" is not a guard. One row called `portal` (an upstream a customer
+ * happens to name that way, a future portal that describes itself) would make `portal_toggle_servers`
+ * a delegable tool, and an agent could then switch its delegator's MCP servers on and off. The rule
+ * is written as a question about reach rather than as a blocklist of one string: if delegating this
+ * handle would hand over `portal_list_servers`, the handle is refused.
+ */
+function ownsTheDirectory(handle) {
+    return ServerDirectoryTool.startsWith(`${handle}_`);
+}
+export function toolServersFrom(input) {
+    const parsed = rows(input.directory);
+    if (parsed === null)
+        return null;
+    // `id` and `name` are both offered as candidates because the portal's directory names them
+    // separately and only one of them is the namespace. The live list decides which.
+    const display = new Map();
+    const offerable = new Set();
+    for (const row of parsed) {
+        for (const candidate of [row.name, row.id]) {
+            if (candidate === undefined || candidate.length === 0)
+                continue;
+            if (ownsTheDirectory(candidate))
+                continue;
+            if (!display.has(candidate))
+                display.set(candidate, row.name ?? row.id ?? candidate);
+            if (row.enabled !== false)
+                offerable.add(candidate);
+        }
+    }
+    const counts = new Map();
+    for (const toolName of input.toolNames) {
+        const handle = serverOf(toolName, display.keys());
+        if (handle === null || !offerable.has(handle))
+            continue;
+        counts.set(handle, (counts.get(handle) ?? 0) + 1);
+    }
+    return {
+        declared: [...display.keys()],
+        servers: [...counts.entries()]
+            .map(([handle, toolCount]) => ({ handle, name: display.get(handle) ?? handle, toolCount }))
+            .sort((a, b) => a.handle.localeCompare(b.handle)),
+    };
+}

package/dist/tools/tools.js

@@ -1,10 +1,24 @@
+import { serverOf } from "@anchrd/intel-contract";
 import { IntelError } from "../shared/intel-error/intel-error.js";
 import { reportUnexpectedError } from "../shared/report-unexpected-error/report-unexpected-error.js";
+import { ServerDirectoryTool, toolServersFrom, } from "./tool-servers/tool-servers.js";
 const CallTimeoutMs = 15_000;
 const MaxTools = 1_000;
 const MaxResultBytes = 1_000_000;
 // Refresh slightly early so a call cannot start with a token that expires mid-flight.
 const RefreshWindowMs = 30_000;
+/**
+ * An agent that delegates nothing — no servers, or no delegator to act for.
+ *
+ * ⚠️ It is answered without touching the token store at all. `delegatedBy` is empty for an archived
+ * agent, one whose definition Intel could not read, and one that was never given tools; asking the
+ * store for the connection of user "" would be a lookup that can only ever fail, on a path that has
+ * already decided the answer.
+ */
+function delegatesNothing(who) {
+    return (who.delegation !== null &&
+        (who.delegation.servers.length === 0 || who.delegation.delegatedBy.length === 0));
+}
 export function createTools(deps) {
     function portal() {
         if (!deps.portalUrl || !deps.sourceAllowed(deps.portalUrl)) {
@@ -12,12 +26,23 @@ export function createTools(deps) {
         }
         return deps.portalUrl;
     }
+    // One lookup per request, before anything else happens: everything below has to know whether it
+    // is answering a person or an agent, and a second lookup could answer differently mid-call.
+    async function acting(actor) {
+        const delegation = await deps.delegation(actor.id);
+        return {
+            actor,
+            connectionOf: delegation?.delegatedBy ?? actor.id,
+            delegation,
+        };
+    }
     // Authorization for tools lives entirely in the portal, so "may this user act" reduces to "does
     // this user have a usable portal token". ⚠️ The token is read per actor and never shared: one
     // operator token for everybody would make every catalog the same one and the portal's Access
-    // policies decorative (ADR-0003).
-    async function accessToken(actor) {
-        const stored = await deps.tokens.read(actor.id);
+    // policies decorative (ADR-0003). For an agent the actor IS somebody else — the delegator — which
+    // is the whole of D30 and the reason this takes an `Acting` rather than a `ToolActor`.
+    async function accessToken(who) {
+        const stored = await deps.tokens.read(who.connectionOf);
         if (!stored) {
             throw new IntelError(401, "portal_not_connected", "The portal has not signed this user in yet");
         }
@@ -33,20 +58,81 @@ export function createTools(deps) {
             // A token that cannot be renewed is dropped: leaving it would keep failing every call with a
             // stale credential. The browser answers this by signing in silently again (#60); an MCP
             // client sees the code and repeats its own authorization.
-            await deps.tokens.clear(actor.id);
+            await deps.tokens.clear(who.connectionOf);
             throw new IntelError(401, "portal_reconnect_required", "The portal sign-in for this user has expired");
         }
-        await deps.tokens.write(actor.id, refreshed);
+        await deps.tokens.write(who.connectionOf, refreshed);
         return refreshed.accessToken;
     }
-    // One live tools/list is both the catalog and the authorization answer: the portal only returns
-    // what this user may reach. Nothing here is cached as a permission.
-    async function capabilities(actor) {
-        const token = await accessToken(actor);
+    async function remoteTools(who) {
+        const token = await accessToken(who);
         const remote = await deps.remote.list(portal(), token, AbortSignal.timeout(CallTimeoutMs));
         if (remote.length > MaxTools) {
             throw new IntelError(502, "tool_catalog_too_large", "The portal returned too many tools");
         }
+        return remote;
+    }
+    /**
+     * The servers the portal says this connection reaches, confirmed against its live tool list.
+     *
+     * ⚠️ Fails rather than answering "none" when the portal keeps no directory. An empty list would
+     * be indistinguishable from "you have no servers", and the difference decides whether a screen
+     * says "connect something" or "this portal cannot be delegated from".
+     */
+    async function serverList(who, toolNames) {
+        if (!toolNames.includes(ServerDirectoryTool)) {
+            throw new IntelError(502, "tool_servers_unavailable", `The portal does not offer ${ServerDirectoryTool}, so its servers cannot be listed`);
+        }
+        const answer = await deps.remote.call({
+            url: portal(),
+            accessToken: await accessToken(who),
+            name: ServerDirectoryTool,
+            arguments: {},
+            signal: AbortSignal.timeout(CallTimeoutMs),
+        });
+        const directory = answer.isError ? null : toolServersFrom({ directory: answer, toolNames });
+        if (directory === null) {
+            throw new IntelError(502, "tool_servers_unavailable", "The portal did not answer with a server list this Intel can read");
+        }
+        return directory;
+    }
+    /**
+     * One live tools/list is both the catalog and the authorization answer: the portal only returns
+     * what this user may reach. Nothing here is cached as a permission.
+     *
+     * ⚠️ For an agent the list is cut to the delegated servers, and the cut is made against the
+     * portal's own directory rather than against the tool names — `tool-servers.ts` says why the
+     * namespace alone is not enough to attribute a tool. The second return value is the attribution
+     * itself, so the audit below names the server the cut actually used rather than guessing again.
+     */
+    async function capabilities(who) {
+        const delegated = who.delegation;
+        const serverOfTool = new Map();
+        if (delegatesNothing(who))
+            return { items: [], serverOfTool };
+        let remote = await remoteTools(who);
+        if (delegated) {
+            const directory = await serverList(who, remote.map((tool) => tool.name));
+            // ⚠️ Attributed against every identifier the portal DECLARED — including rows it marked
+            // disabled — and only then checked against the delegation. Attributing against the offerable
+            // subset (or against the delegation itself) would widen it: with `wiki` delegated and
+            // `wiki_extra` merely declared, `wiki_extra__read` starts with `wiki_` and would be handed
+            // over as a `wiki` tool. The longest match over the widest declared set is the only reading
+            // that no missing row can loosen.
+            const delegatedSet = new Set(delegated.servers);
+            // ⚠️ And the attribution is then required to land on a server that is still OFFERABLE — the
+            // narrow set, enabled and confirmed. Wide for attribution, narrow for permission: a portal
+            // that switches a server off takes it away from the agent here, which is revocation reaching
+            // an agent without anybody touching its definition (D30).
+            const offerable = new Set(directory.servers.map((server) => server.handle));
+            remote = remote.filter((tool) => {
+                const handle = serverOf(tool.name, directory.declared);
+                if (handle === null || !delegatedSet.has(handle) || !offerable.has(handle))
+                    return false;
+                serverOfTool.set(tool.name, handle);
+                return true;
+            });
+        }
         const items = [];
         for (const tool of remote) {
             items.push({
@@ -59,27 +145,63 @@ export function createTools(deps) {
                 }),
             });
         }
-        return items;
+        return { items, serverOfTool };
+    }
+    /**
+     * ⚠️ The refusal that costs nothing. A delegated caller naming a tool outside every delegated
+     * namespace is turned away here — before the token store, before `tools/list`, before the portal
+     * hears anything at all. The authoritative cut still happens in `capabilities`, against the
+     * portal's directory; this one exists so the portal is never touched on behalf of a call that was
+     * always going to be refused, and so the refusal can name the tool and the servers (D30).
+     */
+    function requireDelegated(who, name) {
+        const delegated = who.delegation;
+        if (!delegated)
+            return;
+        if (delegatesNothing(who)) {
+            throw new IntelError(403, "tool_not_delegated", `${name} is not available: this agent has no delegated MCP servers`);
+        }
+        if (serverOf(name, delegated.servers) === null) {
+            throw new IntelError(403, "tool_not_delegated", `${name} is not part of this agent's delegated servers (${delegated.servers.join(", ")})`);
+        }
     }
-    async function requireCapability(actor, name) {
-        const found = (await capabilities(actor)).find((capability) => capability.name === name);
+    async function requireCapability(who, name) {
+        const reachable = await capabilities(who);
+        const found = reachable.items.find((capability) => capability.name === name);
         if (!found) {
             throw new IntelError(404, "tool_not_available", `Tool ${name} is not available to you`);
         }
-        return found;
+        return { capability: found, server: reachable.serverOfTool.get(name) };
     }
-    async function call(actor, input) {
-        if (!actor.canExecute) {
+    async function call(who, input) {
+        if (!who.actor.canExecute) {
             throw new IntelError(403, "tool_execute_forbidden", "Tool execution permission is required");
         }
-        const capability = await requireCapability(actor, input.name);
+        requireDelegated(who, input.name);
+        const { capability, server } = await requireCapability(who, input.name);
         const validation = deps.validate(capability.inputSchema, input.arguments);
         if (!validation.valid) {
             throw new IntelError(400, "tool_arguments_invalid", validation.detail ?? "Invalid arguments");
         }
+        // ⚠️ Written before the call, not after it: an audit that only records what succeeded is a
+        // record of the harmless half. Both principals are named — the agent that acted and the person
+        // whose connection carried it (D30) — and no argument is.
+        //
+        // ⚠️ The server is the one the CUT used, carried out of `capabilities`, not a second guess made
+        // against the delegated handles. Re-deriving it here would name `wiki` for a tool the cut
+        // attributed to `wiki_extra`, and an audit row that names the wrong system is worse than none.
+        if (who.delegation) {
+            await deps.audit({
+                agentId: who.delegation.agentId,
+                applicationId: who.actor.id,
+                delegatedBy: who.delegation.delegatedBy,
+                server: server ?? "",
+                tool: capability.name,
+            });
+        }
         const result = await deps.remote.call({
             url: portal(),
-            accessToken: await accessToken(actor),
+            accessToken: await accessToken(who),
             name: capability.name,
             arguments: input.arguments,
             signal: AbortSignal.timeout(CallTimeoutMs),
@@ -89,41 +211,78 @@ export function createTools(deps) {
         }
         return result;
     }
+    // A token that is gone or beyond renewal is the same answer as never having signed in, so reading
+    // a catalog reports it as a state. Only a portal that does not answer stays an error — the view
+    // has to tell "sign in again" apart from "the portal failed", and a 401 here would otherwise look
+    // like an expired Intel session to the browser.
+    function disconnected(error) {
+        return (error instanceof IntelError &&
+            (error.code === "portal_not_connected" || error.code === "portal_reconnect_required"));
+    }
     return {
         async catalog(actor) {
-            const stored = await deps.tokens.read(actor.id);
+            const who = await acting(actor);
+            if (delegatesNothing(who))
+                return { portalConnected: true, items: [] };
+            const stored = await deps.tokens.read(who.connectionOf);
             // No portal sign-in yet is a normal state, not an error: the browser answers it by running
-            // the silent sign-in and asking again (#60).
+            // the silent sign-in and asking again (#60). For an agent it is the ordinary shape of
+            // revocation — the delegator disconnected, so the agent reaches nothing (D30).
+            if (!stored)
+                return { portalConnected: false, items: [] };
+            try {
+                return { portalConnected: true, items: (await capabilities(who)).items };
+            }
+            catch (error) {
+                if (disconnected(error))
+                    return { portalConnected: false, items: [] };
+                throw error;
+            }
+        },
+        async servers(actor) {
+            const who = await acting(actor);
+            if (delegatesNothing(who))
+                return { portalConnected: true, items: [] };
+            const stored = await deps.tokens.read(who.connectionOf);
             if (!stored)
                 return { portalConnected: false, items: [] };
             try {
-                return { portalConnected: true, items: await capabilities(actor) };
+                const remote = await remoteTools(who);
+                const { servers } = await serverList(who, remote.map((tool) => tool.name));
+                // ⚠️ An agent sees its own delegation, never the delegator's whole shelf. Its catalog is cut
+                // anyway, so the uncut list would grant nothing — it would only tell an agent, and through
+                // it a model, which other systems the person it acts for is connected to.
+                const delegated = who.delegation;
+                return {
+                    portalConnected: true,
+                    items: delegated
+                        ? servers.filter((server) => delegated.servers.includes(server.handle))
+                        : servers,
+                };
             }
             catch (error) {
-                // A token that is gone or beyond renewal is the same answer as never having signed in, so
-                // reading the catalog reports it as a state. Only a portal that does not answer stays an
-                // error — the view has to tell "sign in again" apart from "the portal failed", and a 401
-                // here would otherwise look like an expired Intel session to the browser.
-                if (error instanceof IntelError &&
-                    (error.code === "portal_not_connected" || error.code === "portal_reconnect_required")) {
+                if (disconnected(error))
                     return { portalConnected: false, items: [] };
-                }
                 throw error;
             }
         },
-        execute: async (actor, input) => await call(actor, input),
+        execute: async (actor, input) => await call(await acting(actor), input),
         async test(actor, input) {
-            const capability = await requireCapability(actor, input.name);
+            const who = await acting(actor);
+            requireDelegated(who, input.name);
+            const { capability } = await requireCapability(who, input.name);
             if (capability.annotations.readOnlyHint !== true ||
                 capability.annotations.destructiveHint === true) {
                 throw new IntelError(409, "tool_test_unsafe", "Only explicitly read-only, non-destructive tools can run in the test surface");
             }
-            return await call(actor, input);
+            return await call(who, input);
         },
         async unavailable(actor, names) {
             if (names.length === 0)
                 return [];
-            const available = new Set((await capabilities(actor)).map((capability) => capability.name));
+            const who = await acting(actor);
+            const reachable = await capabilities(who);
+            const available = new Set(reachable.items.map((capability) => capability.name));
             return names.filter((name) => !available.has(name));
         },
     };

package/dist/tools/tools.types.d.ts

@@ -1,4 +1,4 @@
-import type { ExecuteToolInput, TestToolInput, ToolCapability, ToolCatalog, ToolTestResult } from "@anchrd/intel-contract";
+import type { ExecuteToolInput, TestToolInput, ToolCapability, ToolCatalog, ToolServerCatalog, ToolTestResult } from "@anchrd/intel-contract";
 export interface ToolActor {
     id: string;
     email: string;
@@ -35,6 +35,25 @@ export interface RemoteTools {
         signal: AbortSignal;
     }): Promise<ToolTestResult>;
 }
+/**
+ * What an agent's definition delegates, resolved from the Gate Application the caller authenticated
+ * as (D30). `null` from the port means "this caller is not an agent" — the ordinary user path.
+ *
+ * ⚠️ Read fresh on every call and never cached as a permission. It is the same rule the catalog
+ * follows: the answer has to be able to change between two runs without anybody editing anything.
+ */
+export interface ToolDelegation {
+    agentId: string;
+    delegatedBy: string;
+    servers: string[];
+}
+export interface ToolAuditEvent {
+    agentId: string;
+    applicationId: string;
+    delegatedBy: string;
+    server: string;
+    tool: string;
+}
 export interface ToolDeps {
     portalUrl: string | null;
     remote: RemoteTools;
@@ -47,9 +66,12 @@ export interface ToolDeps {
         valid: boolean;
         detail?: string;
     };
+    delegation(applicationId: string): Promise<ToolDelegation | null>;
+    audit(event: ToolAuditEvent): Promise<void>;
 }
 export interface ToolService {
     catalog(actor: ToolActor): Promise<ToolCatalog>;
+    servers(actor: ToolActor): Promise<ToolServerCatalog>;
     execute(actor: ToolActor, input: ExecuteToolInput): Promise<ToolTestResult>;
     test(actor: ToolActor, input: TestToolInput): Promise<ToolTestResult>;
     unavailable(actor: ToolActor, names: string[]): Promise<string[]>;

package/migrations/0015_tools_delegated_from_a_connection.sql

@@ -0,0 +1,15 @@
+-- #208 (D30): an agent's tools are whole MCP servers its owner delegated from the owner's own
+-- portal connection. Nothing about that selection is stored here — it lives in the agent's
+-- definition, versioned in R2 like the rest of the document.
+--
+-- What this file adds is the one lookup the run path needs and `0014` did not provide: a call
+-- arrives authenticated as a Gate Application, and Intel has to answer "which agent is that"
+-- before it may read anybody's portal token. `0014` indexed `node_id` only (it is the primary
+-- key), so the reverse question was a table scan on every delegated tool call.
+--
+-- ⚠️ UNIQUE, not just an index. Two agents sharing one Application would make the lookup ambiguous
+-- and would hand one agent the other's delegation — the same class of hole `AGENT_APPLICATION_KEYS`
+-- refuses a doubly listed id for (D27). The constraint is what makes "one Application per agent"
+-- a fact of the database rather than a promise of the code that writes it.
+CREATE UNIQUE INDEX agent_applications_application_idx
+  ON agent_applications(application_id);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@anchrd/intel-api",
-  "version": "0.7.0",
+  "version": "0.9.0",
   "type": "module",
   "license": "UNLICENSED",
   "repository": {
@@ -43,7 +43,7 @@
   },
   "dependencies": {
     "@anchrd/gate-sdk": "^0.7.0",
-    "@anchrd/intel-contract": "^0.5.0",
+    "@anchrd/intel-contract": "^0.7.0",
     "@modelcontextprotocol/sdk": "^1.30.0",
     "ajv": "^8.20.0",
     "fflate": "^0.8.3",