TL;DR
Internal agents that triage tickets, write reports or reconcile accounts often run on one broad production key that nobody narrowed after the demo. A manager needs to say who answers for that access and show the agent stayed inside its job. Give each agent its own identity with a named sponsor, let the tool layer fetch a narrow, short-lived credential per action, keep secrets out of prompts, traces and saved state, and write the cut-off plan before it is needed.
In this article
8 min read
An agent should not hold credentials the way a person holds a password. The model decides which action it wants to take; the code that runs the tool fetches a credential for that one action, from a secrets manager or the platform’s identity service, and the model never sees it. Around that rule sit four decisions: whose identity the agent acts under, how narrow each tool’s permission is, how long a token stays valid, and how quickly one agent can be switched off without stopping the others.
The question comes up in that shape. In January 2026 an Ask HN thread asked teams whose agents perform database writes, deploys, email and billing calls where the enforcement point sits that the agent “cannot bypass”, and how identity works when agents act for users. In August 2026 a builder on the OpenAI developer forum asked how others keep credentials out of agent context. A July 2026 thread on Reddit’s r/AI_Agents went further: production keys handed to internal agents for a demo deadline, never narrowed, and nobody sure who owned them.
Keep the secret in the tool layer, out of everything the model reads
OWASP’s guidance on system prompt leakage (2025 edition) says to avoid embedding sensitive information such as credentials in prompts, and that authorisation checks “must not be delegated to the LLM” (OWASP LLM07:2025, checked 9 October 2026). A key pasted into a system prompt, or into a tool description so the model can “pass it along”, can be repeated back by the model to anyone who asks cleverly enough.
The prompt is the obvious leak. Two quieter ones are traces and saved state. The OpenAI Agents SDK traces runs by default, and its function spans store the inputs and outputs of tool calls; trace_include_sensitive_data is true unless you change it (tracing guide, openai-agents 0.23.1, checked 9 October 2026). LangGraph checkpointers save a snapshot of graph state at every super-step, and encrypting that state is an option you switch on (checkpointers, checked 9 October 2026). So a tool that returns a token, or an error message that echoes an authorisation header, has just written a secret into two stores that were never designed to hold one.
The practical rules follow from that. A tool returns business data, never credentials. Error messages are scrubbed before they reach the model. The credential lives in a vault or in the platform’s own store: n8n, for example, keeps credentials encrypted in its database and can load them from AWS Secrets Manager, Azure Key Vault, GCP Secret Manager or HashiCorp Vault on its Enterprise plans (n8n external secrets, checked 9 October 2026). Then check that it worked: put a recognisable canary value in a test secret, run the agent, and search the traces, checkpoints and logs for it.
Give each agent its own identity and a named sponsor
Most of the ownership question is answered by not sharing. Google Cloud’s guidance is to create a dedicated service account for each application, avoid service account keys where a safer method exists, and use the account’s description field for a contact person (service account best practices, page updated 7 October 2026). A shared account makes activity hard to trace and access hard to remove.
Microsoft’s identity platform now has a model built for agents. In Microsoft Entra Agent ID, every agent identity needs at least one sponsor, a business representative accountable for the agent’s purpose, access reviews and retention, while owners handle the technical side, including credential management (owners, sponsors and managers, Microsoft Learn, 16 April 2026). Whatever platform you use, that split is the answer to “who owns the agent’s access”: a sponsor who answers for what the agent may do, the way a manager answers for an employee’s account, and a technical owner who keeps the credentials working. Permissions limit what an agent can touch; the separate question of what it is responsible for is covered in roles, not just permissions.
The second identity decision is whether the agent acts as itself or on behalf of a user. OWASP’s entry on excessive agency recommends running extensions in the user’s context with the minimum OAuth scope where the action serves one person (LLM06:2025). A nightly reconciliation job serves nobody in particular and belongs under its own service identity. An agent that drafts replies from one employee’s mailbox should carry that employee’s delegated, narrow token; OAuth token exchange (RFC 8693, January 2020) can record both the user and the acting party in one token.
Scope each tool, not the agent
The OAuth security best current practice says token privileges “SHOULD be restricted to the minimum required” and that tokens should be limited to a specific resource server (RFC 9700, January 2025). For agents the unit is the tool, because one agent’s tools have very different needs.
Illustrative scopes, not a real system
| Tool | What the job needs | Credential |
|---|---|---|
| Ticket triage | Read tickets, add a label and an internal note | Helpdesk token limited to those actions |
| Weekly report | Read three reporting tables | Read-only database role on those tables |
| Nightly reconciliation | Read the ledger, write one reconciliation table | Separate role; no access to payments |
Where a system only offers coarse scopes, such as one API key with full account rights, put the narrowing in code: a wrapper exposes only the listed operations and refuses the rest. That is OWASP’s “complete mediation”, authorisation enforced outside the model, and it is also the enforcement point the HN question was looking for. The Model Context Protocol’s security guidance (specification 2025-11-25) explains the cost of skipping this: a broad token, once leaked, enables “lateral data access”, and revoking it “disrupts all workflows” (MCP security best practices, checked 9 October 2026).
Short-lived tokens limit how long a leak lasts, not what an allowed tool does
AWS asks workloads to use temporary credentials through IAM roles rather than long-term keys (IAM best practices, checked 9 October 2026). Role sessions last an hour by default, and AWS spells out the limit: whoever holds an exposed session credential has access for the duration of the session. Short lifetimes shrink that window. Where a static secret cannot be avoided, a secrets manager can rotate it in both the store and the target system (Secrets Manager rotation).
None of this helps when the agent itself is steered. OWASP’s Top 10 for Agentic Applications (9 December 2025) lists identity and privilege abuse as ASI03, citing leaked credentials that let agents “operate far beyond their intended scope” (OWASP announcement). Simon Willison’s “lethal trifecta” (16 June 2025) names the combination to break: private data, untrusted content and a way to send data out (his write-up). A ticket that contains instructions is untrusted content. If the triage tool can also send email, a fresh, narrow token will still carry out the injected request. Test it: plant an instruction in a test ticket and confirm the tool refuses anything outside its list.
Write the cut-off plan before you need it
Stopping one agent should take minutes and should not stop the others. That only works if each agent has its own identity, which is the point of the earlier sections.
- Disable the agent’s identity. Google recommends disabling before deleting, because disabling keeps the bindings and can be undone; an Entra sponsor or owner can disable an agent identity.
- Invalidate sessions already issued. In AWS, revoking a role’s sessions attaches a deny policy to every session of that role issued before the cut-off, so a role shared with another workload would stop that workload too.
- Rotate any static secret the agent could have read, and revoke its OAuth grants.
- Pause the queue that feeds the agent, so work already accepted does not resume under a new credential.
- Read the per-action log to see what the agent did before the cut-off.
Run the sequence once on a test identity, and time it. The security approval of a tool does not tell you how long this takes in your own systems; only the rehearsal does.
If your agents still run on a key that someone created for a demo, start with a list of what each one holds and what its job needs. Eliyce runs its own agents in production, with sub-agents and retrieval doing real work; its agents page describes a written contract for every tool an agent uses, and states that no customer agent built by Eliyce is in production yet. Talk about your agent.
Frequently Asked Questions
How should an AI agent hold and use the credentials for the business systems it acts on?
It should not hold them at all. The tool layer fetches a narrow, short-lived credential for each action and the model only sees results. Where your platform offers a workload identity (an IAM role, a managed identity, a service account without a downloaded key), use it: there is then no stored secret to leak, only a permission to review.
Should the agent act under its own service identity or on behalf of each user?
Delegated access ties every action to a named person, keeps the agent inside the data that person may already see, and ends when the user withdraws consent; the price is storing and refreshing many user tokens. A service identity is one thing to rotate and revoke, but its log must record which user triggered each action, or the audit trail stops at “the agent”. Under the GDPR’s data minimisation principle the delegated model is often easier to defend for personal data; ask your privacy lead, not the agent’s builder, to confirm that for your case.
If secrets stay outside the model, how can credential handling still fail?
Four ways recur. A code-execution or shell tool runs in the same environment as the credentials and reads them from environment variables, a gap a reply in the OpenAI forum thread raised. One broad token is reused by several tools, so narrowing one tool narrows nothing. The agent writes a value it was shown into long-term memory. And an injected instruction makes a permitted tool do harm with a perfectly valid credential.
Which inventory, log and review show the agent stayed in scope, and who owns its identity?
An inventory row per credential: agent, identity, sponsor, technical owner, system, scopes, lifetime, rotation date and last use. A per-action log that records the decision separately from the execution: identity, on whose behalf, tool, target and the rule that allowed or refused it. A quarterly review in which the sponsor compares granted with used permissions; AWS’s last-accessed data and similar reports show what can be removed. The sponsor signs the review.
How do I give an agent only the access its job needs, and cut it off quickly if something goes wrong?
Write the job as a list of actions per system, grant read-only first, and add each write permission only when a test shows the tool needs it. Give every agent its own identity, then measure your real cut-off time: the token lifetime plus the time to disable, revoke and pause. If that number is longer than you could tolerate, shorten token lifetimes before you widen anything.
