Identity and Access Management is foundational enterprise security. AI agents do not change that.
But autonomous agents expose an important limitation:
Knowing who a workload is does not fully answer what that workload should be able to do during execution.
An IAM policy might tell you that an agent identity can access GitHub. It may not tell you which binary is making the request, which local files the agent can read, where the credential can be used, which external destinations the agent can contact, whether the agent can invoke an unapproved MCP tool, or which model endpoint receives enterprise data.
These concerns belong to a broader agent-runtime security model.
IAM answers an essential question
IAM is primarily concerned with:
Identity -> Resource -> Permission
For example:
principal: data-agent
resource: analytics bucket
action: read
That is critical.
An autonomous agent, however, operates inside an execution environment:
User
|
v
Agent process
+-- filesystem
+-- shell
+-- network
+-- credentials
+-- APIs
+-- MCP
`-- model provider
The enterprise has to secure that whole path.
Agent risk exists before the IAM request
Suppose an agent has legitimate permission to read a customer dataset.
IAM correctly allows the read. But the agent also has unrestricted outbound internet access.
Now the risk becomes:
Customer data
|
v
Agent
|
v
Unapproved endpoint
The IAM policy did its job. The problem was uncontrolled runtime egress.
This is why agent security needs multiple enforcement layers.
Credentials create another gap
An IAM design may issue a legitimate token to an agent. But what happens after issuance?
Can the agent read the token, write it to disk, put it in logs, include it in a prompt, send it elsewhere, or pass it to a child process?
Identity architecture needs credential-handling architecture.
One stronger pattern is credential mediation:
Agent
|
opaque reference
|
v
Trusted proxy
|
approved destination
|
real credential inserted
OpenShell's provider model is an example of this approach.
IAM usually does not constrain local filesystem behavior
Cloud IAM can restrict cloud APIs. It does not automatically stop an agent from reading:
~/.ssh/id_rsa
~/.kube/config
.env
other source repositories
local cached credentials
Those are runtime and filesystem controls.
A secure agent environment therefore needs an explicit local access boundary.
IAM usually does not control arbitrary internet egress
Imagine an agent with perfectly designed cloud IAM. The agent can access one data bucket. It also has open internet access.
A compromised reasoning path can retrieve authorized data and send that data somewhere unauthorized.
The resource permission is least privilege. The full agent architecture is not.
Network policy must therefore be designed alongside IAM.
Tool authorization introduces a different dimension
MCP and other agent tool systems make this even more obvious.
An agent may authenticate to one MCP server that exposes:
read_status
create_ticket
restart_service
delete_service
rotate_credentials
Authentication to the server should not necessarily authorize every tool.
You need:
Agent identity
+
Tool authorization
+
Downstream resource authorization
Process behavior matters
What if the agent launches an unexpected binary, installs a malicious package, invokes privileged system behavior, manipulates namespaces, or accesses the Docker socket?
IAM does not answer these questions.
Process identity, capabilities, seccomp, sandboxing, and workload isolation do.
Docker itself combines namespaces, cgroups, capabilities, and kernel hardening. Agent security builds on those concepts while adding agent-aware policy.
Model access is another form of authorization
An enterprise may approve:
Agent A -> hosted model
Agent B -> private NIM
Agent C -> regulated private endpoint
Different workloads may contain different data.
Model routing is therefore a security decision. The agent should not necessarily be free to send its context to any inference endpoint.
Think in terms of an authorization stack
A more complete architecture is:
Human Identity
|
v
Agent Identity
|
v
Runtime Boundary
/ | \
/ | \
Process Network Filesystem
\ | /
\ | /
Credential Policy
|
v
Tool / API Auth
|
v
Resource IAM
IAM remains at the heart of the system. It simply does not stand alone.
Add execution context to your decisions
For sensitive agents, authorization may need to consider:
- agent identity;
- workspace;
- binary;
- destination;
- protocol;
- API operation;
- credential;
- model endpoint;
- data classification;
- environment;
- user identity.
This is closer to policy-based execution control.
OpenShell's model illustrates the distinction
OpenShell separates the agent from the policy enforcement layer.
Its Gateway owns policy and platform state, while the sandbox Supervisor applies controls around filesystem, process, network, credentials, and inference. OpenShell also supports workspace boundaries and role-based platform access.
That makes IAM part of the design without pretending identity alone is the design.
A practical example: SRE agent
Bad architecture:
SRE Agent
+-- cluster-admin kubeconfig
+-- open internet
`-- full shell
Better architecture:
SRE Agent
+-- dedicated workload identity
+-- namespace: payments
+-- read pods/logs
+-- limited restart capability
+-- observability read
+-- incident API write
`-- approved network destinations only
IAM handles several permissions. Runtime policy handles the rest.
Security teams should ask two questions
Identity question
Who is this agent?
Capability question
What can this agent actually cause to happen?
Both matter.
IAM remains essential—but it needs a runtime partner
As AI systems become more autonomous, security programs will need to combine identity with execution policy.
The objective is not to replace IAM. It is to prevent the assumption that if the identity is authorized, every action performed by the agent runtime must therefore be safe.
Identity tells us who the agent is.
A security boundary tells us what that agent is allowed to become capable of doing.
How Anpu Labs helps
Anpu Labs maps agent identity alongside runtime capability. Our Secure Agent Infrastructure Assessment identifies agent identities, systems, credentials, tool access, network paths, runtime privileges, data exposure, and existing IAM controls.
We then design an architecture that combines enterprise identity with sandboxing, least privilege, credential mediation, network enforcement, and security observability.
References
- NVIDIA OpenShell — How OpenShell Works: https://docs.nvidia.com/openshell/about/how-it-works
- NVIDIA OpenShell — Workspaces: https://docs.nvidia.com/openshell/latest/how-it-works/workspaces
- NVIDIA OpenShell — Providers: https://docs.nvidia.com/openshell/how-it-works/providers/overview
- Docker Engine Security: https://docs.docker.com/engine/security/
