Skip to contentAitium

Blog

Why every tool call passes through a registry

Ungoverned dispatch means any tool, any version, any agent. Exact identities, per-agent grants, and mandatory expiry are the alternative.

In a governed runtime, every tool call passes through a registry before it runs. If the tool isn't registered — exact identity, exact version — with an active grant for the calling agent, the call doesn't run. Full stop. This sounds bureaucratic until you've watched the alternative: agents discovering and invoking whatever tools happen to be lying around, at whatever version, with no record of who allowed it.

Why it matters

Tool dispatch is the highest-leverage moment in an agent system. Everything the agent can affect flows through it: files, APIs, shells, subagents, money. An ungoverned tool call is an ungoverned action. And 'the agent probably won't call anything weird' is not a security posture — it's a hope, and hopes don't survive contact with prompt injection.

Versioning is the part people underestimate. A tool named 'deploy' at version 1.4 and version 2.0 can be completely different software. If the grant says 'deploy' without a version, the agent's permissions silently change every time the tool updates. Exact version pins mean the grant means what it said when it was issued. No ranges, no semver cleverness — the identity is the name plus the version, and both are exact.

What the fix looks like

A registry with three properties. First, governed identity: every tool registers under an exact identity — namespace, name, version — with a hash of its definition, so a changed tool can't masquerade as the approved one. Second, subject-keyed grants: a grant authorizes one agent (one scope identity) to discover or call one exact tool version. Grants carry the issuer, the reason, and a mandatory expiry — permissions that never expire are permissions nobody revisits. Third, admission at two points: discovery (can the agent even see this tool?) and pre-dispatch (is the grant still active, unrevoked, unexpired, right now?).

The enforcement is fail-closed and boring, which is the point. A refused call fails fast with a clear reason — not a hang, not a silent skip. The refusal is audited, so the operator sees exactly what was attempted and denied. And revocation is a first-class operation: revoke the registration or the grant, and the next admission check fails. No grace periods, no cached permissions outliving their welcome.

Yes, this means someone has to decide what each agent may touch before it runs. That's not overhead. That's the job.

One more property worth stating: the registry is boring on purpose. It doesn't judge whether a tool is good, safe, or well-written — it records identity and answers admission questions. Policy lives in the grants, not in the registry. Separation of mechanism from policy is what keeps the thing auditable: the record says what was allowed, the grant says who decided, and neither pretends to be the other.

← All articles