Map the task to a separate identity
The service owner should name the exact resources and actions needed for an agent task, then select an identity whose permissions match that scope. Prefer a separate short-lived credential where the provider supports it. Record issuer, audience, expiration, permitted operations, environment and revocation method without copying the value into the inventory. Keep production, research and personal-account credentials separate so a useful test does not inherit unrelated authority.
Review indirect privilege as well as explicit scope. A credential that reads a secret store, edits workflow code or changes another account’s recovery details can have greater effective power than its name suggests. Check which environment variables, credential helpers, identity endpoints and mounted files the agent process can use. Keeping a secret out of the prompt does not protect it if the same process can retrieve it freely from the filesystem.
Deliver secrets through a narrow execution path
Use the service’s supported secret or workload-identity mechanism and expose the credential only to the component making the authorized request. Do not paste real values into prompts, repository files, report drafts or broad tool descriptions. OWASP’s secrets-management guidance covers lifecycle, access and auditing. Our operating recommendation is to give the model a nonsecret reference or task result when it does not need the raw credential.
For container builds, Docker documents secret mounts rather than build arguments or persistent image environment variables. This reduces persistence through the build mechanism, but does not make a malicious build instruction safe: code receiving a secret can still copy or transmit it. Do not supply valuable credentials while building or testing an untrusted repository. Use dummy credentials or a separately reviewed retrieval stage with limited network and resource access.
Review output and account actions for exposure
Prevent debug mode, command tracing and error handling from dumping authorization headers, full environments or connection strings. Check generated reports, archives, screenshots, task histories and shared links before exporting them. Redaction is a useful layer, but transformed or partially encoded values may evade a simple matcher. Keep logs useful through credential identifiers and request correlation rather than printing the credential to prove which one was used.
Monitor the accepting service for unusual operations, destinations and new authority created through the agent identity. A leak may occur through a legitimate API call, attachment or artifact rather than an obvious outbound request to a suspicious host. Keep task and service-side audit records connected so an investigator can distinguish a model proposal from the operation actually completed by the execution tool.
Keep source material separate from the authority to act.
Original Web3Sec diagram. On small screens, scroll the figure or open the full-size version.
Rehearse expiration, revocation and compromise
Use a designated test credential to perform one allowed action, one denied action and a retry after expiration or revocation. Verify the result at the receiving service and check whether refresh tokens, cached sessions or newly issued credentials remain. Then run a synthetic leak drill with a clearly fake secret in a test log, confirming that the right owner receives the event and knows where to disable access.
If a real credential is exposed, stop the affected path, preserve restricted evidence and revoke or replace it from a trusted environment. Review actions taken before revocation, including uploads, role changes, new tokens and scheduled work. Remove public artifacts where possible, while assuming copied material cannot be recalled. Resume the task with corrected scope and a tested delivery path; deleting the chat or rotating only the visible key is not sufficient closure evidence.
Controls to take away
- Secret storage and permission scope solve different problems.
- A secret mount protects delivery mechanics, not malicious consuming code.
- Revocation must address sessions and authority created before containment.
Work through the boundary.
These local worksheets turn the review questions into a plan. They do not inspect or change the actual account or environment.
Build a permission review plan ↗
Select the capabilities you are considering and review approvals, revocation and evidence before connecting an agent.
Take this to your next review
Working checklist
Use this as a starting point, then assign owners and record evidence in your team's own system. Checks here reset when you leave or reload this note.
0 of 5 reviewed
Common questions
Is a secret safe just because I never pasted it into the prompt?
Not necessarily. The agent process may retrieve it from environment variables, mounted files, credential helpers or a secret store. Review that reachable access and provide only the authority the task needs.
Does a build-secret mount make an untrusted build safe?
No. A mount can reduce secret persistence through the build mechanism, but code that receives the value can still copy or transmit it. Use dummy credentials for untrusted build instructions.
What should I check after revoking an exposed agent credential?
Confirm access fails at the receiving service, then review refresh tokens, cached sessions, newly created credentials, role changes, uploads and scheduled work. Deleting a conversation does not retract completed actions or copied secrets.
Sources & further reading
The references below support this note. Adapt the procedures to your systems, access model and recovery requirements.
A correction or a better primary source? Send Raiders the article URL and evidence. Editorial policy.