Enforce authorisation at the tool boundary

How to make a policy decision matter when an agent has several ways to reach the same system.

Follow the credential

An agent that can read a customer record might also know a deletion endpoint exists. The useful question is what the downstream system would do if the agent tried it. If a token in the agent’s environment can delete records, an instruction to avoid deletion has no bearing on what the API will accept.

Inventory credentials available to the agent, including tokens mounted into workers, inherited service identities, and credentials held by tools it can invoke. Track the authority each credential carries. Two different endpoints that accept equivalent credentials present the same enforcement problem.

Put the executor in charge of the call

In a reference design, the agent proposes an action and submits its arguments. A trusted executor authenticates the caller, validates the action and resource, and runs a policy check. The executor makes the downstream call with a credential the agent cannot obtain. It should hold only the permissions needed for its set of supported operations.

Start by testing one destructive operation. Give a support agent permission to read a record in its tenant, then request deletion of the same record through the executor. Next, attempt deletion directly. If the second path works, narrow the agent’s credential or apply equivalent enforcement to that endpoint before moving on.

Check what happens when policy is unavailable

A network failure is an authorisation failure mode. If a policy service is unreachable, hold privileged writes until a decision can be made. If your design caches low-risk decisions, define what the cache key covers, how long a decision remains valid, and how revocation takes effect. A cached decision for one tenant or argument set cannot safely cover another.

Include these cases in the deployment check alongside tool discovery, credential inventory and direct calls. Record how the executor handled each attempt. A valid rollout test should show both that a legitimate operation still works and that an unauthorised route actually fails.

Review the change process

A newly added connector can reopen an old route. Record the execution identity, network path and tool inventory as part of the integration review. When a connector is added or an executor credential is rotated, rerun the denied direct-call test and the legitimate operation test from the actual worker environment. Keep those checks close to deployment so the enforcement model remains valid as the system changes.