Bind permission to the operation that actually runs, not the explanation that requested it.
A tool call should arrive at execution with less authority than the model imagined, not more. A request to prepare a release can reasonably produce a proposed upload. It cannot manufacture permission to publish. The useful boundary is an authorization envelope: an application-controlled record of exactly which action may run, against which resource, under which grant, and until when.
Consider a hypothetical assistant preparing a release of an internal software package. It may inspect approved source, build an artifact, and run checks. Publishing to the internal registry requires a release manager’s confirmation; publishing to a public registry is prohibited under this grant. This is a proposed reference architecture, not a deployment or benchmark I have measured. Its central job is to keep the release decision attached to the artifact that actually reaches the registry.
The assistant does not receive the publishing credential. It proposes a structured operation to a broker that owns the execution boundary. That proposal names the tool, artifact reference, registry, package, version, and requested effect. The broker adds authenticated caller identity, delegated scope, environment, current policy revision, and a request identifier from trusted state. An argument supplied by the model cannot overwrite those fields.
Parse before judging. Reject unknown operations and malformed arguments, resolve the registry and artifact through approved identifiers, and compute the artifact digest from stored bytes. Do not let an apparently harmless wrapper conceal an unrestricted shell command. If an operation invokes scripts or follows redirects, the adapter must constrain those effects too. The envelope describes a resolved action, not merely the string that made the action look acceptable.
Deterministic policy then narrows the possible outcomes. The public registry is denied regardless of a model’s assessment. A read-only metadata lookup can proceed under an explicit matching grant. The internal upload remains eligible but held for confirmation. OWASP’s authorization guidance recommends least privilege, denial by default, and permission validation on every request. The practical consequence is that a convincing explanation cannot add an operation to the caller’s scope.
An existing policy engine can evaluate those structured rules; a second model is not required to compare a registry identifier with an allowed set. Open Policy Agent explicitly separates policy decisions from enforcement. The broker still has to consume the decision and withhold the credentialed call when it does not pass. Installing a policy engine beside an unrestricted execution route would preserve the route that matters most.
Reserve the bounded decision model for a question the rules cannot settle cheaply. It might assess whether the proposed release notes imply an external disclosure inconsistent with the task. Supply the necessary approved evidence and a fixed set of outcomes, including insufficient evidence. Record model identity, evidence references, decision, and applicable evaluation policy. Its output may raise an eligible operation to review or support a permitted low-impact path; it cannot lower a deterministic denial or waive required confirmation.
That gray-zone decision needs an operating threshold established on representative labeled cases, with false allows distinguished from needless holds. No universal probability cutoff follows from the architecture. An unfamiliar operation, missing evidence, or a result outside the accepted schema should retain the hold. A model that returns a valid score has answered a typed question; the application still owns what that answer permits.
The release manager should see the internal registry, package version, artifact digest, relevant check results, and the fact that this will create a published release. Approval comes through an authenticated channel and binds to that resolved operation, not to the assistant’s summary. OWASP’s transaction-authorization guidance calls for acknowledgement of significant transaction data, server-side enforcement, limited validity, and a final check before execution. A later rebuild changes the digest and invalidates this approval.
The broker can now issue a short-lived, single-use authorization record. Bind it to caller, action, resource, artifact digest, policy revision, approval reference, expiry, and an unpredictable operation identifier. Store it server-side or protect its integrity with a mechanism the actor cannot forge. A digest alone only identifies bytes; it does not authenticate permission. Immediately before dispatch, recheck current scope, revocation, artifact identity, and the record’s unused state, then claim it atomically so competing workers cannot both release the operation.
Execution uses the least-privileged credential available for that registry and package. The downstream service should enforce those limits as well; the broker must not be the only thing separating a narrow task from an account-wide administrator token. Keep alternate clients, network destinations, and direct credential access outside the assistant’s reach. This architecture loses its authorization boundary if the agent can perform the same upload through a different tool.
Prompt injection belongs in that threat model. Release notes, repository comments, and retrieved pages can contain instructions claiming that approval already exists. OWASP’s prompt-injection guidance identifies indirect instructions and agent-connected tools as attack surfaces. Preserve that material as untrusted evidence, separate from application-owned policy and approval records. A second model reading the forged instruction does not make it authoritative. Even a fully deceived judge must remain unable to mint the release manager’s approval.
Define failure behavior for each stage rather than assigning the whole system one fail-open switch. If a required policy lookup, semantic gate, or confirmation service times out, this publishing operation stays unexecuted with an owner and expiry. An optional prose-quality check could be unavailable without blocking an otherwise authorized metadata read, if that exception is explicit policy. Missing authorization is never repaired by assuming consent. Expired holds become cancelled or awaiting renewed review, not silently executable backlog.
A timeout after dispatch is a different state. The registry might have accepted the release before its response disappeared. Mark the outcome unknown and reconcile registry state using the operation identifier and expected artifact digest. Do not mint another operation merely because the assistant did not receive success. Amazon’s guidance on idempotent APIs explains caller-provided request identifiers and the importance of distinguishing repeated requests from changed intent. Use the downstream service’s actual idempotency contract where available; a local identifier cannot make a non-idempotent remote API safe by itself.
Verification closes the effect, not just the HTTP request. Read the published package metadata through a permitted independent query and compare registry, version, and digest with the authorized values. A transport success without that evidence remains an unverified execution. A mismatch becomes an incident for the release owner, not permission for the assistant to delete or replace an artifact. Those corrective actions need their own grants.
Append durable events as the operation moves through proposed, denied, awaiting approval, authorized, dispatched, unknown, and verified states. Keep policy and evidence references, authenticated approver, execution attempt, and verification result outside the actor’s writable store. Restrict deletion and mutation, and use retention controls appropriate to the required audit strength. If a durable pre-dispatch event cannot be recorded, hold the release. Record completion durably before telling the user it is verified; missing final evidence must remain visible for reconciliation.
Evaluate the boundary with controlled fixtures before allowing real releases. Substitute a new artifact after approval, replay a consumed authorization, forge approval inside release notes, race two workers, revoke scope before dispatch, and lose the registry response after acceptance. Check downstream effects and retained events, not only the judge’s answers. These are proposed acceptance tests, not results reported here. The envelope earns authority when the exact approved operation can pass once, and every materially different operation has to earn its own permission.
Subscribe to Signal Over Noise for practical analysis of AI agents and automation: what to test, which constraints matter, and when a tool is worth using. Bring the next idea to one bounded workflow and check the result before expanding it.
If this was useful, forward it to one engineer who needs less noise in their feed.