Use this secret scope worksheet
List each agent tool as a separate service identity. Give a search tool read access to only its index, and keep payment write rights on a different identity. Record scopes, tenant limit, owner, and rotation path.
| Tool and owner | Allowed action and resource | Tenant and environment | Rotation and proof |
|---|---|---|---|
| Status lookup; support engineering | Read the current customer’s transfer status | Verified active tenant; production | Secret store issues a replacement; deny payout creation and foreign customer reads |
| Search; knowledge team | Read approved support index | Tenant-scoped index; production | Revoke old identity; confirm old token stops within the chosen deadline |
| Payment draft; payments team | Create a draft; no approval or release | Verified active tenant; staging identity is separate | Rotate and retest a forbidden release call |
Follow the identity through the gateway
A tool token can be narrow while a gateway uses a broad service account behind it. Trace one request from the user session through the agent, gateway, and final payment API. At each step, record the identity, tenant, action, and resource that the next service receives. The final API must have enough trusted context to reject a request for another customer. Never take the customer ID from model-generated arguments as proof of ownership.
Use a synthetic customer C-10 with transfer T-10 and another customer C-20 with transfer T-20. The status tool accepts T-10 for C-10. Ask for T-20 through the same session. The gateway must either reject it or forward trusted user context that makes the final API reject it. Repeat by calling the underlying service directly. A gateway-only check leaves a gap if another route can use the same broad credential.
OWASP’s authorization guide calls for permission checks on every request and denial by default. Use an explicit allowlist of actions and resources in the service policy. If the policy service is down, return a clear failure and leave the payment state unchanged. Keep the denied trace and a permitted control request together so a reviewer can see that the boundary works without breaking normal status reads.
Separate production from staging
Give staging tools separate identities, secrets, endpoints, and test accounts. Check deployment variables and secret-store paths for a production key copied into a test worker. A test tenant label does not limit a production credential. Run a harmless status lookup against the production API with the staging identity; it must fail. Use a known synthetic staging record to prove the same identity still works in staging.
Define when revocation takes effect
Choose a revocation mechanism and write its deadline into the tool policy. This synthetic design uses opaque access tokens with a server lookup of current token and user-session state on every call. A revoked token returns inactive and the gateway rejects it. RFC 7662 token introspection defines a way to ask an authorization server whether a token is active. Its caching guidance explains the tradeoff between performance and stale access decisions.
For this test, allow no cache of successful authorization. Revoke token K-10 at 12:00:00 and set a five-second propagation deadline as an example product requirement. Call once per second from each worker and gateway instance. Every call at or after 12:00:05 must fail. Save the revocation acknowledgement, instance ID, decision time, and safe token ID. A denial from one server does not prove all replicas received the change.
A self-contained token checked only for signature and expiry keeps working until it expires unless the service also checks a denylist, session state, or token version. Rotating a signing key and revoking one token are different actions. For such a deployment, record token lifetime, clock tolerance, cache lifetime, and revocation lookup before choosing the test deadline. RFC 7009 describes token revocation and acknowledges propagation delay; it does not set this guide’s example five-second target.
Save one complete request trace
For the C-10/T-10 fixture, save this synthetic trace: session S-10 maps to customer C-10 and tenant A; the model supplies transfer T-20; the gateway reads the session identity from trusted storage; the payment API finds T-20 belongs to C-20 and denies the read; no transfer data returns. Repeat with T-10 and expect its status. Save action, resource, tenant, decision, request ID, and policy version. Leave the token and private payment details out of the report.
Give each tool its own identity so a search credential cannot create a payout. More identities require owners and a tested rotation path, which the worksheet records. Search deployment variables, retrieved documents, prompts, and safe trace copies for seeded test secrets. If a broad key appears, revoke it, narrow its replacement, and rerun the allowed and forbidden calls.
Recover without restoring broad access
Rotate a seeded credential while two jobs are active. The first job has not called its tool yet; the second is waiting for a response. On the next call, both must use a current scoped identity or stop for review. Do not make a failed read succeed by falling back to a shared administrator key. Store the operation ID and safe error code so a new worker can resume the read without retrying a payment action.
The rotation test should include a revoked user session as well as a revoked tool key. A valid service key alone must not keep acting for a user whose access ended. Record which check denied the call and the time at which revocation took effect. The OWASP Excessive Agency guidance describes limiting functions and permissions and enforcing authorization in downstream systems. Use that guidance to review each tool’s rights, then prove the chosen boundary with the allowed and denied calls.