The Blast Radius of a Leaked Agent Key

Assume the holder can skip the agent UI

Start the assessment with a copied credential and an independent HTTP client. RFC 6750 defines bearer access through possession: the holder does not demonstrate possession of a separate cryptographic key. If your agent credential works this way, an attacker need not persuade Claude Code, Codex or Cursor to approve anything. Confirmation dialogs in the original client do not constrain another client using the same credential.

This generic protected-resource request illustrates the bearer header defined in RFC 6750. It must travel over HTTPS; the token below is a dummy value, and the resource path is illustrative.

GET /resource HTTP/1.1
Host: api.example.com
Authorization: Bearer example-access-token

Do not assume every API key implements OAuth. Establish which endpoint accepts the actual credential, whether another factor or network restriction is enforced there, and whether requests work outside the original session. A key nickname such as research-only records intent. Only a rejected request demonstrates a boundary.

Draw the reachable authority, including indirect access

For each key, trace a path from accepting endpoint to allowed source, callable operation, accessible records and upstream identity. Where gateway and upstream policies both apply, an operation must pass both. Repeat the trace for every allowed source, then combine the reachable records and actions. Counting connectors alone misses the difference between ten public documents and one production customer database.

Follow indirect paths too. If an allowed file contains another token, or an allowed operation can mint credentials, the first key may expose additional authority. Record that dependency separately. A stolen gateway key and code execution on its host are different starting conditions; this assessment should say which one it assumes.

Compare two keys for the same research task

Consider a hypothetical agent that summarizes support trends. Its shared team key reaches a ticket system, an analytics database and a release system. Ticket export can return customer conversations, the database includes customer identifiers, and the release connection permits deployment changes. None of those capabilities becomes irrelevant because the prompt asks only for a summary.

A narrower design gives this agent its own credential, limits it to the support connection and a reporting dataset, and excludes release access. The reporting dataset omits direct customer identifiers; ticket access excludes private attachments. These are proposed controls that must be implemented and tested at the relevant service, rather than assumptions about what a source-scoping checkbox does.

The resulting assessment should name the remaining exposure: selected ticket text and reporting rows can still leave through successful reads, while deployment changes should be unreachable. Write down those outcomes beside the denied operations. For implementation details, use a separate scoped key for each agent.

Estimate throughput explicitly. In an illustrative system allowing 60 successful reads per minute, each returning at most 100 records, a ten-minute window permits up to 60,000 returned record instances, assuming no separate bulk export or response path. That is a conditional ceiling, not a prediction of unique records stolen. An export operation returning an entire archive would invalidate the estimate.

Read-only narrows damage, not disclosure

A credential that cannot modify a customer table may still retrieve its contents. Treat confidentiality and mutation as separate columns in the assessment. Restricting a support agent to reads can remove ticket deletion from its reach while leaving sensitive conversations exposed. Reduce the records and fields available upstream when the task does not need them.

The MCP tools specification says annotations must be considered untrusted unless they come from trusted servers, and requires servers to implement access controls. A read-only annotation describes claimed behavior; it does not itself enforce database permissions. Test the implementation behind it. For the permission model, see read-only defaults for agent access.

Likewise, keeping an operation out of the displayed tool list does not prove direct invocation is denied. Include direct-call tests in the assessment. If the credential can also edit shared memory or skills, include those writes: changing text consumed by later sessions is a separate capability from reading business data.

Measure the window until access actually stops

Count the exposure window from the earliest plausible leak until the last successful unauthorized request. Separate detection time, operator response and enforcement delay. A short dashboard workflow helps only after someone notices the leak. Expiry can bound continued use, but check whether a refresh token or another credential can extend it.

RFC 7009 notes possible propagation delays after OAuth token revocation and makes related-token invalidation depend on authorization-server policy. Do not assume revoking an access token also removes every refresh token. For a proprietary API key, verify the provider's behavior separately. In either case, measure resource access after revocation rather than relying solely on the dashboard status.

For OAuth bearer access, RFC 6750 defines the following invalid-token response. An insufficient-scope response uses 403 instead. The MCP authorization specification also requires audience validation: a token issued for another resource should not be accepted.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token"

Revocation cannot recall an exported archive or undo a completed deployment. Identify long-running exports and queued mutations separately. Review successful calls during the window; where available, use returned-record counts and job identifiers to distinguish attempted access from completed effects.

Where SPYN3 fits

SPYN3 keeps upstream credentials envelope-encrypted in the workspace; agents hold a SPYN3 API key or OAuth token. A key can be limited to chosen sources. call:tools reaches only tools upstream marks read-only; unmarked tools count as writes and require call:write_tools. Revoking a key or disconnecting a source takes effect on the next call. Proxied calls are audit-logged with source, tool, outcome and duration. These controls narrow a leaked key's reach; they do not prevent disclosure through permitted reads.

Accept the key only after testing its boundary

Run a rehearsal with a disposable credential and synthetic records. Keep upstream credentials separate from the agent credential: MCP's security guidance prohibits token passthrough and explains how direct downstream access can bypass gateway controls. Centralizing access also concentrates trust in the gateway; compromise of that service requires its own assessment.

1. From an independent client, retrieve one permitted synthetic record and confirm an excluded source and record are denied.
2. Attempt a harmless prohibited write against a test object. Confirm no mutation occurred, including through direct invocation of an undisplayed tool.
3. Measure maximum page and export sizes. Recalculate the disclosure ceiling using those values and the enforced request limits.
4. Revoke the disposable credential while requests are active. Record the last accepted request and first rejection, and inspect any outstanding job.
5. Verify the audit trail identifies the credential and affected source without recording the secret itself. Confirm other agents retain access through their separate credentials.

The result should be a sentence an incident responder can act on: this key can read these datasets, perform these mutations, and stops working within this measured interval. Keep unresolved boundaries explicit. Revisit the estimate whenever a connection, upstream grant or bulk operation changes.