Policy-Locked Tool Use in Multi-Agent Systems

Practical context

A proposed evaluation method for explicit authorization boundaries in agent workflows.

Evaluate assistant workflows with explicit behavior, provider and review boundaries.

Implementation and research boundary

The MCP implementation validates tool arguments, the local completion path applies bounded constitutional checks, and the gateway has a separate episode-admission implementation. These are distinct mechanisms with distinct scopes.

A general policy-locked multi-agent workflow must identify every privileged operation, its authorizer, its refusal behavior and its audit record. This note proposes that evaluation; it does not claim complete mediation of all tools or live service authorization.

Proposed authorization model

Define an operation as an actor, a capability, a resource and bounded arguments. The proposed policy decision should bind to that specific operation so that an approval for reading one document cannot authorize deleting another. Keep data admission, tool invocation and model-output checks distinct: the inspected code implements examples of each boundary, not a single universal security layer. Persona routing chooses behavior and must never be treated as an authorization decision.

Protocol and failure cases to evaluate

Create synthetic actors with allowed and denied capabilities. Submit the same well-formed operation with each identity, then vary the resource, argument bounds and request freshness. Include duplicate requests, malformed payloads, revoked permissions and a timeout after submission. Define whether a retry is idempotent and which identifier links request to outcome. This is an application-level study design; it does not assert that every listed retry or revocation control already exists in ABI.

Evidence required for a claim

An acceptance record should identify the tested policy revision and operation, while rejection evidence should show that the protected side effect did not occur. Check the authoritative storage or execution result, not merely an approval message. A passing local test supports that tested path and policy. It does not prove that another transport, tool, or deployed service shares the same boundary. Before adoption, inventory all side-effecting entry points and test attempts to bypass the intended authorizer. Publish redacted synthetic evidence and methodology rather than customer records.

Evaluation before adoption

For a customer pilot, choose a concrete task and identify whether it uses local templates or an explicitly configured provider. Evaluate task correctness, escalation and data handling with representative inputs before making quality claims.