Why the credential boundary is the boundary that matters
An agent may generate text, process files, call tools, retrieve external content, and interact with enterprise systems. The question that decides how much a bad run can affect is what it can reach on its own. An agent that holds a production token can act with it, whatever else surrounds the run. An agent that holds no credential can only propose an action to the tool gateway, which decides, holds the credential, and acts. The gateway becomes the single place where identity, policy, argument checks, approvals, and evidence apply. It doesn't make the agent safe by itself. Permissions, input handling, monitoring, and the target system's own controls still matter.
Define the boundary across identity, tools and destinations
Bound the things that create real impact rather than the compute the run happens to use. Decide which tools are registered and bound to the approved agent version, which arguments are allowed, which credential the gateway holds and on whose behalf it acts, which destinations may be reached, which actions need a person, and what the run records. Separate production and non-production access. Start from no access, then add the minimum the job needs. The exact boundary depends on the workload, but it should be explicit, testable, and visible in the run evidence.
- Registered tools and the approved version they are bound to
- Argument constraints and the written policy for each tool
- Whose credential the gateway uses, and its scope
- Outbound destinations, protocols and methods
- Which actions stop for a person, and who that person is
- What is recorded for each decision and each action
- Separation between organisations, agents, environments and runs
Treat egress as part of agent authority
An agent can disclose data or trigger an action through an outbound connection even when everything else about the run is tightly held. Egress policy should define approved domains, APIs, protocols, methods, and destinations for the job. Resolve dynamic destinations carefully, read the destination from the registry at the moment of use rather than from the run's own request, and protect against redirects or indirect routes that bypass the intended allowlist. Refuse link-local and private ranges outright so cloud metadata endpoints are never reachable. Where possible, route enterprise-system access through governed integrations that apply identity, action policy, data handling, and evidence rather than opening general network access.
Keep credentials out of the agent entirely
The aim is not short-lived secrets in the run. It is no secrets in the run. Hold the credential at the gateway, scope it to the narrowest resources and actions, and make it unreadable to everything else, including the screens that configure it. Keep credentials out of prompts, files, tool arguments, and traces, where neither the model nor a reviewer needs them. Destroy the credential when the connection is removed, an agent is withdrawn, or activity looks wrong, and test that queued and active work stops afterwards.
Test the boundary with realistic failure modes
Ask the agent to call a tool it was not bound to, reach a destination that is not approved, act on a record outside its remit, and continue after its access is removed. Include content that attempts to redirect the agent toward a prohibited action, since an agent reading hostile text is the ordinary case rather than the exotic one. Confirm that the decision happens outside the model, that the target system is unchanged, that a person was asked where the policy said so, and that the evidence records the attempt and the result without exposing sensitive values.
Choose persistence deliberately
Some workflows need state between runs and some do not. Decide which state belongs to the run, which belongs in an approved application store, and which belongs in the existing system of record. Persist only what the next run requires, with ownership, retention, access controls, and provenance. Do not let a convenient shared workspace quietly become long-term memory for several agents or customers.
A boundary review
Review the boundary as an operating contract. The required strength depends on the job, but every capability the agent has should be intentional and testable.
- Credentials: who holds them, what scope they carry, how they are removed
- Tools: which are bound, to which version, with which argument constraints
- Network: domains, addresses, protocols, methods, redirects and private ranges
- Approvals: which actions stop, who may answer, what happens if nobody does
- Data: what the model sees, what is replaced, and what the record keeps
- State: per-run memory, shared stores and systems of record
- Separation: between organisations, agents, environments and runs
- Shutdown: timeout, credential removal, cancellation and the evidence of it
Frequently asked questions
Where should an AI agent's credentials live?
Not with the agent. Hold them at the tool gateway that executes actions, so the agent proposes an action and something else decides, holds the credential, and acts.
Why do AI agents need network egress controls?
Outbound connections can disclose data or trigger actions. Egress policy restricts the destinations, protocols, and operations a run may reach, and it should be applied where the action executes.
Is a credential boundary enough to secure an AI agent?
No. It bounds what the agent can reach. Identity, permissions, runtime policy, data protection, human approval, monitoring, and target-system controls govern what it may do.
What should the run record afterwards?
The proposed action, the decision and why, the approval if one was asked for, the outcome, and the kind of sensitive value that was replaced rather than the value itself.