Autonomous agents need credentials.
If an agent needs to create a GitHub pull request, query a database, update Jira, invoke a model, or access cloud infrastructure, something must authorize the request.
The dangerous assumption is:
Therefore the agent must possess the real reusable credential.
It does not always have to.
A stronger architecture separates credential possession from credential use.
The traditional pattern
Many early agent deployments use environment variables:
GITHUB_TOKEN=...
MODEL_API_KEY=...
DATABASE_PASSWORD=...
The application reads the variable and sends it upstream.
This is simple. It also means any process capable of reading the environment may gain access to the secret.
For an autonomous coding agent, that may include shell commands, child processes, generated scripts, packages, debugging output, and logs.
The secret becomes part of the agent's ambient authority.
The attack path
Imagine an agent with a GitHub personal access token.
A malicious instruction causes:
echo $GITHUB_TOKEN
If the agent can read the value, the problem becomes:
Real credential
|
v
Agent process
+-- logs
+-- prompt
+-- shell
`-- network
The organization now has to trust every layer around the process not to expose it.
Better pattern 1: workload identity
Whenever possible, avoid static credentials entirely.
Use cloud workload identity, short-lived OAuth tokens, federated identity, GitHub Apps, service identities, or signed requests.
Agent Workload
|
v
Identity Provider
|
short-lived token
|
v
Approved Service
This reduces the value of stolen credentials.
Better pattern 2: credential broker
Another approach is keeping credentials in a trusted component.
Agent
|
v
Credential Broker
+-- policy check
+-- destination check
`-- secret retrieval
|
v
Service
The agent does not necessarily receive the long-lived secret.
OpenShell's provider model
OpenShell implements a form of credential mediation.
A provider represents service credentials and their authorized endpoint context.
Inside the sandbox, the agent can receive an opaque placeholder. When a request passes through the OpenShell proxy, the platform can resolve the real credential immediately before forwarding the request.
Two conditions must be satisfied:
- network policy allows the request;
- the credential is bound to that destination.
Conceptually:
Agent
|
placeholder credential
|
v
OpenShell Proxy
+-- Destination approved? YES
+-- Binding valid? YES
|
v
Insert real credential
|
v
GitHub
But a request to an unrelated endpoint does not receive the actual credential.
Why destination binding matters
A normal environment variable is just text.
Even if the token is only useful against GitHub, the agent can still copy that text elsewhere.
With destination-aware credential mediation, the runtime can refuse to resolve the real value outside its intended destination.
That turns a secret into something closer to a constrained capability.
Secrets management is not enough by itself
Vault, AWS Secrets Manager, Azure Key Vault, and similar systems solve an important problem:
Where should the credential be stored?
Agent security introduces another question:
How should the credential be used at runtime?
A mature architecture needs both.
Secret Store
|
v
Credential Driver / Broker
|
v
Runtime Policy
|
v
Agent Request
Storage and usage policy are separate layers.
Scope every credential
A credential should be constrained along multiple dimensions.
Resource scope
Which repository, database, bucket, or account?
Action scope
Read, write, delete, administer?
Environment scope
Development, staging, production?
Destination scope
Where can the credential be presented?
Time scope
How long is it valid?
Agent scope
Which workload may use it?
The strongest credential is one that becomes useless outside the intended execution path.
Avoid shared agent credentials
If ten agents share the same token, incident response becomes harder.
Prefer:
agent-a -> identity-a
agent-b -> identity-b
agent-c -> identity-c
or short-lived workload-specific credentials minted from a common identity system.
Then you can answer:
Which agent performed this action?
Separate the human from the agent
A common anti-pattern is allowing the agent to inherit the developer's session.
Human has broad access
|
v
Agent inherits broad access
Instead:
Human authenticates
|
v
Launch authorized sandbox
|
v
Agent receives workload-specific identity
The agent's permissions should match the workflow, not the maximum privilege of the human operator.
Rotation and revocation matter more for agents
Autonomous systems can make requests faster and more frequently than humans.
Design for short TTLs, automated rotation, immediate revocation, central detachment, and policy updates without code changes.
Log credential use without logging the credential
Capture:
agent
sandbox
provider
destination
timestamp
result
Avoid logging the secret itself.
The objective is to know how the capability was used without recreating the exposure problem.
The principle to remember
Secrets management asks:
Where is the secret?
Agent credential security should also ask:
Does the agent actually need to know the secret?
Frequently, it only needs the ability to perform a particular authorized action.
How Anpu Labs helps
Our Secure Agent Infrastructure Assessment inventories every credential an agent uses. We document source, storage, scope, rotation, visibility, downstream resource, whether the raw value reaches the agent, and whether the credential can be reused elsewhere.
We then design a target model using workload identity, enterprise secret stores, OpenShell providers, and least-privilege policy.
References
- NVIDIA OpenShell — Providers: https://docs.nvidia.com/openshell/how-it-works/providers/overview
- NVIDIA OpenShell — How OpenShell Works: https://docs.nvidia.com/openshell/about/how-it-works
- NVIDIA OpenShell — Extensibility: https://docs.nvidia.com/openshell/latest/extensibility/overview
