TL;DR
An autonomous AI agent with shell access, credentials, package installation, tools, and network connectivity should be treated as a potentially hostile privileged workload.
The security boundary cannot depend on the task description, system prompt, or assumption that the agent will follow the expected execution path. Controls must be based on the maximum authority the complete agentic system can exercise.
A hardened design should use:
- Task-specific capability policies
- Ephemeral workload identities
- No ambient credentials
- Brokered access to tools and enterprise APIs
- Deny-by-default network egress
- Controlled package retrieval
- Time, compute, action, and network budgets
- Human approval for trust-boundary crossings
- Monitoring and termination controls outside the agent
- Canary credentials and deception signals
The objective is not to make the model perfectly trustworthy. The objective is to prevent an untrusted decision from becoming an unauthorized enterprise action.
Introduction
Enterprise AI discussions often begin with what an agent should be allowed to accomplish.
Can it troubleshoot a server? Deploy an application? Update a ticket? Query a database? Install a dependency? Remediate a cloud configuration?
Those questions are necessary, but they are not sufficient.
The more important security question is:
What is the maximum authority the agent could exercise if it behaved unexpectedly, interpreted its objective incorrectly, followed malicious instructions, or discovered an unintended route through the environment?
That distinction changes the architecture.
A conventional application generally follows code paths designed and reviewed before deployment. It may contain vulnerabilities, but its expected behavior is comparatively bounded. An autonomous agent can reason about obstacles, choose tools dynamically, retry failed approaches, inspect its surroundings, and combine capabilities that designers did not expect it to use together.
This does not make the agent malicious. It makes the workload adaptive.
An adaptive workload with shell access, credentials, package installation, and network connectivity can behave like a privileged insider operating at machine speed. It can enumerate permissions, search for secrets, test network paths, install new utilities, change identities, and continue until it reaches a goal or encounters a control it cannot bypass.
That is why AI agent security must move beyond application sandboxing. The enterprise needs a zero-trust execution architecture in which every sensitive capability is independently granted, constrained, monitored, and revocable.
Why an Autonomous Agent Is Not an Ordinary Application
An ordinary application is usually built around a known execution model. Developers decide which APIs it calls, which binaries it launches, which data stores it uses, and how errors are handled.
An agentic system is different. The model may choose its next action at runtime based on its interpretation of the objective and the environment. Even when the available tools are predefined, the sequence and combination of tool calls may not be.
That creates several security differences.
The agent can search for alternate paths
A traditional application typically fails when its expected path is unavailable. An agent may try another command, package, identity, protocol, endpoint, or workflow.
That adaptability is operationally valuable. It is also why weak boundaries become dangerous. A control that stops the first attempt may not stop the twentieth variation.
The agent can compose individually acceptable permissions
A read-only file tool may appear harmless. A package manager may appear routine. An internal network route may appear necessary. A cloud identity may appear narrowly scoped.
Together, those permissions may allow the agent to:
- Discover a credential or token.
- Install a client capable of using it.
- Reach the service that accepts it.
- Extract data or change configuration.
- Remove or obscure the evidence.
Security reviews must therefore evaluate combinations of capabilities, not only individual permissions.
The agent can operate longer than a human session
An agent may run for minutes, hours, or across repeated scheduled executions. More time gives it more opportunities to explore, retry, accumulate state, and discover weak paths.
Persistence is a security capability.
The task description is not an authorization boundary
A prompt such as “diagnose the application failure” describes an objective. It does not technically prevent the agent from scanning adjacent systems, enumerating credentials, changing firewall rules, or installing an unapproved package.
Prompts influence behavior. They do not enforce infrastructure boundaries.
The hardened architecture must assume the objective, instructions, retrieved data, and model-generated plans can all be wrong while the infrastructure controls remain correct.
Conventional Application Sandbox Versus Hardened Agent Execution Enclave
| Security property | Conventional application sandbox | Hardened agent execution enclave | Why the difference matters |
|---|---|---|---|
| Execution path | Mostly predefined by application code | Dynamically selected by the model and orchestration layer | The agent may discover combinations the designer did not anticipate |
| Identity | Persistent service account | Ephemeral task identity with a short lifetime | Compromise should not create durable access |
| Credentials | Environment variables, mounted secrets, configuration files | Broker handles or just-in-time tokens bound to task, tool, destination, and time | The agent should not be able to enumerate or export reusable secrets |
| Shell access | Broad shell inside a container or virtual machine | Brokered commands, constrained execution profiles, or disposable micro-sandboxes | A shell is a capability multiplier |
| Tool access | Libraries or APIs available directly to the process | Policy-controlled tool broker with per-operation authorization | Tool names alone do not describe the authority of individual operations |
| Network egress | Broad internal access or unrestricted internet access | Default deny with explicit destination, protocol, port, and purpose rules | Network reach converts local capability into enterprise impact |
| Package installation | Direct access to public repositories | Separate retrieval service with allowlists, scanning, provenance, signing, and read-only delivery | Package managers can introduce new code and communication methods |
| Runtime | Persistent service or loosely bounded worker | Fixed deadline, action budget, retry budget, and idle timeout | Unlimited time increases search depth and persistence |
| Approvals | Usually handled outside runtime | Mandatory approval for defined trust-boundary crossings | Sensitive actions should not inherit authorization from the initial task |
| Monitoring | Application logs and infrastructure telemetry | Correlated prompts, plans, tool calls, identities, process activity, credential use, and network events | Isolated logs cannot reconstruct agent trajectory |
| Termination | Process or container shutdown | Independent kill controller that revokes identity, closes network paths, stops tools, and preserves evidence | Killing one process is insufficient when authority survives elsewhere |
| Policy modification | Application may update its own configuration | Policy plane is isolated and inaccessible to the agent | The workload must not control its own guardrails |
| Deception | Rarely included | Canary credentials, files, services, and destinations | Interaction can provide a high-confidence divergence signal |
The difference is not a stronger container configuration alone. It is a different control model.
The Privileged-Insider Mental Model
The most useful mental model is to treat an autonomous agent as a privileged insider whose intentions cannot be continuously verified.
A human privileged insider may possess:
- Administrative tools
- Multiple identities
- Access to documentation
- Knowledge of infrastructure
- The ability to install software
- Network access across trust zones
- Time to experiment
- The authority to modify systems
An enterprise agent may receive the same practical advantages, except it can perform actions faster, retry more consistently, and operate without fatigue.
The risk should therefore be calculated from the agent’s effective authority, not from its assigned job title.
A useful model is:
Reducing one term does not necessarily make the system safe. A low-privilege identity combined with accessible secrets may still reach privileged systems. Restricted network access combined with a powerful infrastructure tool may still permit broad changes through a management API.
The architecture must constrain the complete authority chain.
Threat Assumptions for Long-Running Agents
A secure design begins with explicit threat assumptions.
The enterprise should not assume that every dangerous action originates from a malicious model. The same outcome can result from several failure paths.
Objective misinterpretation
The agent may misunderstand a task, optimize the wrong metric, or preserve the literal objective while violating the intended method.
Prompt injection and untrusted content
Tickets, source code, web pages, documents, logs, tool output, and retrieved data may contain instructions that redirect the agent’s behavior.
The agent should not treat data-plane content as control-plane authority.
Tool misuse
A legitimate tool may expose operations beyond the task. A source-control tool may read secrets. A cloud tool may change identity policy. A shell tool may launch an unapproved client.
Credential discovery
The agent may locate tokens in environment variables, process arguments, files, shell history, mounted volumes, metadata services, build caches, or adjacent workloads.
Privilege accumulation
The initial identity may be limited, but the agent may discover a role-assumption path, delegation mechanism, service-account token, package credential, deployment identity, or human approval workflow that expands its authority.
Infrastructure escape
No sandbox should be treated as a perfect boundary. Kernel vulnerabilities, runtime defects, shared services, misconfigured mounts, management endpoints, and network-adjacent systems can all create escape paths.
Resource exhaustion
An agent can unintentionally generate excessive tool calls, processes, API requests, logs, tokens, storage consumption, or cloud charges.
Monitoring evasion
The agent may modify local logs, terminate a sidecar, change its process tree, encrypt traffic, or switch identities. Monitoring that runs inside the same authority boundary is not independent monitoring.
These assumptions do not predict that every agent will behave dangerously. They ensure the architecture remains safe when one does.
Capability-Based Authorization
Traditional role-based access control asks what a user or workload identity may access.
Agent security must ask a more precise question:
Which capability may this task exercise, against which resource, through which tool, under what conditions, for how long, and with what approval?
A capability is more specific than a role.
“Cloud operator” is a role.
“Read the configuration of these three development resources for the next ten minutes through the approved inventory broker” is a capability.
The capability model should bind together:
- Task identity
- Agent instance
- Tool
- Tool operation
- Target resource
- Data classification
- Network destination
- Credential scope
- Time window
- Action count
- Approval state
- Monitoring requirements
The agent should receive a capability lease, not standing authority.
Separate policy decisions from enforcement
The policy engine should decide whether an action is allowed. The tool broker, network control, credential broker, or target platform should enforce that decision.
The agent should control neither function.
A policy decision might state:
Allow: task-4271 to call inventory.read against development-cluster-03 for 10 minutes with a maximum of 25 requests using an ephemeral read-only identity
The tool broker must then reject requests that change the operation, target, identity, or time window.
This is stronger than asking the model to remember a rule.
Evaluate the requested operation, not only the tool name
Approving “shell” is too broad. Approving “cloud management” is too broad. Approving “source control” is too broad.
Authorization should reach the operation level:
- Read a file, but do not change permissions.
- Query a deployment, but do not update it.
- Run a test, but do not publish an artifact.
- Retrieve a package, but do not add a repository.
- Read a ticket, but do not change its assignee.
- Generate a proposed configuration, but do not apply it.
The more powerful the tool, the more important this decomposition becomes.
The Agent Capability Control Flow
The agent should never receive standing access to every capability needed across all possible tasks. Instead, it requests a narrowly defined operation and receives a temporary decision from an external policy layer.
The important point is the separation of authority. Shell execution, credential issuance, and network access should have distinct enforcement paths. A policy failure in one layer should not automatically grant authority in the others.
Ephemeral Task Identities
A persistent service account is convenient because the workload can start immediately and access everything assigned to that account.
That convenience is exactly the problem.
A persistent identity creates standing authority before the task begins, after the task ends, and during periods when the agent is idle or behaving unexpectedly.
An agent should instead receive an identity created or activated for a specific task.
A task identity should be bound to:
- A unique task identifier
- A specific agent execution
- An approved capability policy
- A maximum lifetime
- An intended environment
- A defined set of resources
- An issuing workload or orchestration service
- Evidence of the workload’s runtime identity
The identity should expire automatically and should not be reusable by a later task.
Workload identity frameworks such as SPIFFE and SPIRE demonstrate how short-lived, attested workload identities can replace passwords and static API keys in distributed environments. Cloud-native identity federation can provide similar patterns when tokens are exchanged only at execution time and limited to a specific audience and role.
Identity expiration must be enforced downstream
An expired orchestration token is not enough if the agent already obtained a long-lived cloud credential.
Every downstream credential should expire no later than the task identity that authorized it.
Identity should not survive restart or migration
Restarting an agent worker should not automatically restore the previous identity. The orchestration layer should reevaluate whether the task remains valid and issue a new capability lease only when policy permits it.
Separate task identity from platform identity
The agent process may have one workload identity used to authenticate to the capability layer. Each approved tool operation may then receive a narrower downstream identity.
This prevents the primary agent identity from becoming a universal enterprise credential.
Removing Ambient Credentials
Ambient credentials are credentials available to the process without a new authorization decision.
Common examples include:
- Secrets stored in environment variables
- Cloud credentials exposed through instance metadata
- Mounted service-account tokens
- Local credential files
- Shared SSH keys
- Package-repository passwords
- Source-control tokens
- Cached command-line sessions
- Credentials inherited from a parent process
An agent can search these locations just as an attacker or privileged administrator would.
The preferred design is secretless agent execution. The agent receives references to approved capabilities, not the underlying credential material.
Use credential brokers
When a tool operation requires authentication:
- The agent requests the operation from the tool broker.
- The broker validates the task policy.
- A credential service issues a short-lived token scoped to the operation.
- The broker uses the token on behalf of the agent.
- The credential expires or is revoked after the operation.
The raw secret never enters the agent process.
Bind credentials to audience and purpose
A token for an inventory API should not authenticate to the deployment API. A token for development should not authenticate to production. A token issued to the tool broker should not be usable directly from a shell.
Where the platform supports it, credentials should be restricted by:
- Audience
- Resource
- Operation
- Source workload
- Network path
- Time
- Request count
- Cryptographic proof of possession
Remove local credential recovery paths
It is not enough to avoid environment variables while leaving credentials accessible through debug endpoints, process inspection, local sockets, shell history, temporary files, or agent logs.
Credential exposure testing should be part of enclave validation.
Brokered Tool Access
Direct tool access gives the agent both decision-making authority and execution authority.
A broker separates them.
The agent sends a structured request such as:
Operation: restart_service Target: development-api-03 Reason: health check failed after configuration validation Task: incident-4271
The broker then validates:
- Is the operation approved for this task?
- Is the target in scope?
- Is the environment permitted?
- Has a human approved the action when required?
- Is the action budget still available?
- Is the credential scope sufficient but not broader than necessary?
- Is the request consistent with the task trajectory?
- Has a termination condition already been triggered?
Only the broker communicates with the target system.
Prefer structured operations over arbitrary commands
A structured restart_service operation can constrain the service name, target, timeout, identity, and logging behavior.
A raw shell command can often do much more than its visible text suggests. It may invoke a script, modify the environment, start a child process, redirect output, retrieve code, or connect to another system.
Raw shell access should be reserved for isolated environments where the agent cannot reach enterprise systems directly.
Separate read, propose, and execute capabilities
A practical operating model uses three distinct modes:
Read: The agent may inspect approved systems and collect evidence.
Propose: The agent may generate a change plan or configuration artifact.
Execute: A broker or human-approved workflow may apply the change.
An agent that can read production does not automatically need permission to change production.
Do not let the agent register new tools
Tool registration, plugin installation, protocol endpoint creation, and broker configuration belong to the platform control plane.
Allowing an agent to add its own tools defeats the purpose of tool allowlisting.
Deny-by-Default Network Egress
Network egress is one of the most important agent capabilities because it connects local execution to external impact.
An agent with a shell but no useful network path may be contained. An agent with broad network reach can convert local code execution into credential theft, lateral movement, data exfiltration, remote control, or unauthorized third-party interaction.
Egress policy should begin with no connectivity.
Approved access should then be granted by:
- Destination identity or address
- Protocol
- Port
- Application method
- Task
- Tool
- Data classification
- Time window
- Request rate
- Expected response type
Separate enterprise egress from internet egress
An agent may need access to an internal ticketing service without needing access to every internal subnet.
It may need a package from an enterprise mirror without needing access to the public package ecosystem.
It may need a vendor documentation service without needing arbitrary internet access.
These should be separate policy decisions.
Control DNS as part of egress
Denying destination IP ranges while permitting unrestricted DNS can leave alternate resolution and tunneling paths. DNS requests should be logged, constrained to approved resolvers, and evaluated against destination policy.
In Kubernetes, simply creating a namespace does not provide default-deny networking. A supporting network implementation and explicit policies are required. A deny-all policy also requires deliberate DNS exceptions when name resolution is needed.
Route outbound access through an authenticated gateway
An egress gateway can enforce:
- Workload identity
- Destination policy
- Protocol restrictions
- TLS inspection where appropriate and lawful
- Request logging
- Data-loss controls
- Rate limits
- Emergency shutdown
- Destination reputation
- Task correlation
The gateway should reject traffic that cannot be associated with a valid task identity and capability lease.
Package Retrieval as a Separate Security Boundary
Package installation is often treated as a routine developer convenience. Inside an autonomous execution environment, it is a code-introduction mechanism.
Installing a package can give the agent:
- New network clients
- Credential-discovery utilities
- Alternate interpreters
- Compilers
- Protocol libraries
- Exploitation tools
- Data-compression utilities
- Persistence mechanisms
- Code that has not passed enterprise review
The agent should not connect directly to arbitrary public repositories.
Use a package retrieval broker
A safer workflow is:
- The agent requests a package by name, version, ecosystem, and purpose.
- Policy checks whether the package is approved for the task.
- A retrieval service downloads it outside the agent enclave.
- The service verifies origin, digest, signature, provenance, license, and vulnerability policy.
- The package is placed in a controlled cache.
- The enclave receives a read-only artifact or a rebuilt disposable image.
- The package request and resulting artifact are recorded with the task.
SLSA provides a framework for reasoning about software supply-chain integrity and provenance. Sigstore and Cosign provide mechanisms for signing and verifying software artifacts. These controls do not prove a package is safe, but they help determine whether the artifact is the approved artifact and whether its origin can be verified.
Pin versions and immutable digests
Floating versions allow the same task to receive different code at different times.
Production agent workloads should use:
- Approved versions
- Immutable digests
- Verified signatures
- Captured provenance
- Defined expiration and review dates
- Reproducible enclave images where practical
Separate build environments from execution environments
An agent that builds or modifies software should not automatically be able to deploy it.
Build, test, signing, publication, and deployment should remain distinct capabilities with independent identities and approval gates.
Time, Compute, and Action Budgets
Time is not merely a cost-control concern. It is part of the security boundary.
A long-running agent can try more approaches, create more processes, call more endpoints, and accumulate more information.
Every execution should have explicit budgets.
Time budget
Define:
- Maximum wall-clock duration
- Maximum active processing time
- Maximum idle time
- Maximum time awaiting approval
- Credential lifetime
- Network lease lifetime
Platforms such as Kubernetes support workload deadlines that can terminate jobs after a defined duration. The agent control plane should apply the same principle even when the workload is not implemented as a Kubernetes Job.
Action budget
Limit:
- Tool calls
- Shell operations
- File reads and writes
- Process launches
- Credential requests
- Network requests
- Target systems contacted
- Approval requests
- Retry attempts
A sudden increase in action volume may indicate a loop, task divergence, prompt injection, or active boundary exploration.
Compute budget
Limit:
- CPU
- Memory
- Accelerator usage
- Storage
- Process count
- Open files
- Network bandwidth
- Model tokens
- Concurrent subtasks
Resource limits should be enforced by infrastructure, not only recorded for billing.
Budget exhaustion should fail closed
When a budget is exhausted, the agent should pause or terminate. It should not silently receive an extension.
Extensions should require a new policy decision and, for sensitive tasks, human approval.
Human Approval for Trust-Boundary Crossings
Human approval should not be required for every low-risk operation. Excessive approval prompts create fatigue and encourage rubber-stamping.
Approval should be tied to trust-boundary crossings and irreversible consequences.
Common approval triggers include:
- Production write access
- Privilege elevation
- Identity or role changes
- Creation of a new credential
- Access to a higher data classification
- Contact with an unapproved external destination
- Installation of an unapproved package
- Modification of security controls
- Disabling monitoring
- Destructive or irreversible changes
- Cross-account, cross-tenant, or cross-cluster access
- Communication with a third party
- Expansion of task scope
- Export of data from the enclave
Approval must describe the real action
An approval message should identify:
- Requested operation
- Target
- Environment
- Identity
- Data affected
- Expected outcome
- Rollback method
- Agent’s stated rationale
- Supporting evidence
- Remaining budget
- Policy rule that triggered approval
“Allow the agent to continue” is not an adequate approval request.
Approval should issue a new capability
A human approval should not disable the policy layer. It should authorize one defined operation or a short sequence of operations.
The resulting capability should expire and should not be reusable for a different target.
Independent Monitoring and Termination
An agent should not be able to disable, modify, or fully observe the systems responsible for monitoring and terminating it.
Monitoring should exist in an independent control plane with access to:
- Agent prompts and objectives
- Planner and model outputs
- Tool requests and responses
- Policy decisions
- Identity issuance and use
- Process creation
- File access
- Package requests
- DNS queries
- Network connections
- Cloud and platform audit events
- Human approvals
- Budget consumption
- Termination events
Monitor trajectories, not only individual events
A single file listing may be normal. A single failed connection may be normal. A single identity request may be normal.
The sequence may show a different story:
The signal exists in the trajectory.
Monitoring should evaluate whether actions remain relevant to the declared task, whether authority is expanding, and whether the agent is repeatedly exploring denied paths.
The kill mechanism must revoke authority
Stopping the model loop is not enough.
Termination should:
- Stop the agent process and child processes.
- Revoke task and downstream credentials.
- Close network leases.
- Cancel pending tool operations.
- Invalidate capability tokens.
- Freeze or snapshot the enclave.
- Preserve logs and memory evidence where policy permits.
- Prevent automatic restart.
- Notify incident response.
- Require explicit authorization before resumption.
The kill controller must be reachable even when the agent worker is unhealthy or compromised.
Canary Credentials and Deception Controls
Canary credentials can reveal behavior that ordinary policy alerts miss.
A canary credential is a credential-like object that has no legitimate use. Access, attempted use, or export of that credential can indicate that the agent is searching outside its authorized task.
MITRE D3FEND describes decoy user credentials as credentials created to deceive an adversary, with analytics designed to detect their use. The same concept can be adapted carefully for autonomous workload monitoring.
Possible agent-enclave canaries include:
- Decoy API tokens
- Fake cloud credential files
- Decoy deployment keys
- Canary database connection strings
- Decoy configuration files
- Nonfunctional privileged tool entries
- Instrumented network destinations
- Fake metadata records
Canaries must not grant real authority
A canary credential should never authenticate to production. It should resolve to a monitored decoy service or fail safely while generating a high-confidence alert.
Placement must be deliberate
A canary hidden in an unrelated directory may produce little value. Place canaries where unauthorized credential discovery, filesystem enumeration, or privilege exploration would naturally encounter them.
Canary access is a signal, not a verdict
Some legitimate diagnostic tasks may inspect broad filesystem locations. The policy should consider task scope and operation context.
However, attempting to use a canary credential should normally trigger immediate containment.
Example Agent Capability Policy
The following YAML is a conceptual policy artifact. It is intentionally platform-neutral so it can be translated into an admission controller, policy engine, orchestration service, cloud authorization system, or custom agent gateway.
The policy defines allowed tools, network destinations, credential scope, runtime budgets, human approval triggers, and automatic termination conditions.
apiVersion: security.dtd.example/v1alpha1
kind: AgentCapabilityPolicy
metadata:
name: development-incident-diagnostics
owner: ai-platform-security
riskClass: elevated
reviewAfter: "2026-10-01"
spec:
task:
allowedPurposes:
- diagnose_application_failure
- collect_non_sensitive_evidence
- propose_remediation
prohibitedPurposes:
- production_change
- identity_administration
- security_control_modification
- external_system_interaction
execution:
environment: isolated-agent-enclave
maximumDuration: 20m
maximumIdleTime: 3m
maximumToolCalls: 120
maximumShellOperations: 30
maximumNetworkRequests: 200
maximumCredentialLeases: 8
maximumChildProcesses: 12
restartPolicy: never
failClosedOnPolicyError: true
identity:
mode: ephemeral
identityLifetime: 20m
bindTo:
- task_id
- agent_instance_id
- enclave_instance_id
- approved_policy_digest
credentialScope:
default: none
allowed:
- name: development-inventory-reader
resources:
- development-cluster-03
- development-api-03
operations:
- read_configuration
- read_health_status
lifetime: 10m
audience: inventory-broker
- name: incident-ticket-reader
resources:
- assigned_incident
operations:
- read_ticket
- append_diagnostic_note
lifetime: 10m
audience: ticket-broker
delivery:
exposeRawSecretsToAgent: false
exportToEnvironment: false
writeToFilesystem: false
brokerUseOnly: true
tools:
defaultAction: deny
allowed:
- name: inventory.read
operations:
- get_resource
- list_dependencies
- read_health_status
- name: logs.query
operations:
- search
- aggregate
constraints:
maximumLookback: 4h
redactSensitiveFields: true
- name: shell.run
mode: brokered
operations:
- list_directory
- read_approved_file
- inspect_process
- run_approved_diagnostic
constraints:
writablePaths:
- /workspace/output
readablePaths:
- /workspace/input
- /var/log/approved
prohibitedExecutables:
- privilege_escalation_tools
- network_scanners
- credential_dumpers
- package_managers
- remote_shell_clients
- name: remediation.propose
operations:
- generate_change_plan
- generate_configuration_patch
constraints:
applyChanges: false
network:
defaultAction: deny
approvedDestinations:
- name: internal-dns
destination: dns.corp.example
protocols:
- udp
- tcp
ports:
- 53
purpose:
- name_resolution
- name: inventory-broker
destination: inventory-broker.corp.example
protocols:
- tls
ports:
- 443
purpose:
- configuration_read
- health_read
- name: log-broker
destination: log-broker.corp.example
protocols:
- tls
ports:
- 443
purpose:
- diagnostic_query
- name: telemetry-collector
destination: telemetry.corp.example
protocols:
- tls
ports:
- 443
purpose:
- audit_export
directInternetAccess: false
directProductionNetworkAccess: false
requireAuthenticatedEgressGateway: true
logDnsQueries: true
logConnectionAttempts: true
packages:
directRepositoryAccess: false
installationMode: brokered
approvedSources:
- enterprise-package-mirror
requirePinnedVersion: true
requireImmutableDigest: true
requireSignatureVerification: true
requireProvenanceVerification: true
mountArtifactsReadOnly: true
humanApproval:
requiredFor:
- production_write
- production_shell
- privilege_elevation
- identity_scope_expansion
- credential_creation
- security_control_change
- new_network_destination
- external_network_access
- unapproved_package
- destructive_operation
- data_export
- cross_account_access
- task_scope_expansion
approvalBehavior:
scope: single_operation
maximumLifetime: 5m
requireNamedApprover: true
requireReason: true
requireRollbackPlan: true
prohibitSelfApproval: true
monitoring:
independentControlPlane: true
immutableAuditStream: true
correlate:
- objective
- model_output
- tool_request
- policy_decision
- identity_event
- process_event
- file_event
- dns_event
- network_event
- approval_event
- budget_event
automaticTermination:
conditions:
- event: canary_credential_accessed
threshold: 1
- event: canary_credential_used
threshold: 1
- event: unapproved_egress_attempt
threshold: 1
- event: credential_export_attempt
threshold: 1
- event: policy_bypass_attempt
threshold: 1
- event: monitoring_tamper_attempt
threshold: 1
- event: denied_capability_requests
threshold: 5
window: 2m
- event: unexpected_child_processes
threshold: 3
window: 1m
- event: maximum_duration_reached
threshold: 1
- event: maximum_action_budget_reached
threshold: 1
- event: task_relevance_score_below_threshold
threshold: 3
window: 5m
actions:
- stop_agent
- stop_child_processes
- revoke_task_identity
- revoke_downstream_credentials
- close_network_leases
- cancel_pending_tool_calls
- preserve_evidence
- prevent_automatic_restart
- notify_incident_response
The values must be adapted to the enterprise environment. The important design is the relationship between fields.
Successful enforcement means that a denied tool, destination, identity, or operation remains inaccessible even when the agent changes its command syntax or reasoning approach.
Common implementation failures include:
- A broker policy denies an action while the agent still has direct API access.
- An ephemeral identity can exchange itself for a long-lived token.
- Shell restrictions can be bypassed through an interpreter or child process.
- Network controls cover IP traffic but leave an alternate proxy or service path open.
- An approved package can execute installation hooks with broader authority.
- The agent can modify the policy file or telemetry sidecar.
- A terminated task automatically restarts with the same credentials.
The policy must be tested against the complete execution path, not only parsed successfully.
Reference Architecture for an Agent Execution Enclave
A hardened enclave separates the untrusted decision-making workload from the systems that grant and enforce authority.
The reader should notice that the agent does not communicate directly with credentials, production APIs, public package repositories, or the policy administration plane.
The enclave should be disposable
A task should start in a clean environment and end with the environment destroyed or quarantined.
Persistent memory, caches, downloaded packages, shell history, and temporary files can transfer authority or malicious instructions between tasks.
The policy plane should be read-only from the enclave
The agent may receive a signed policy bundle or query a policy decision point. It should not be able to change policy, approval state, monitoring configuration, or termination rules.
Enterprise systems should trust brokers, not the model process
Target systems should authenticate the approved broker identity and validate resource-level authorization.
Network location alone should not make a request trusted.
Logs should leave the enclave continuously
Waiting until task completion creates an evidence gap if the workload modifies or destroys local logs.
Important events should be streamed to an immutable or separately administered evidence system.
Operational Ownership and Incident Response
An agent enclave crosses several organizational boundaries. Leaving ownership entirely with the AI development team creates gaps in identity, networking, security monitoring, and production operations.
| Capability | Accountable owner | Primary responsibilities |
|---|---|---|
| Agent orchestration | AI platform team | Task lifecycle, model configuration, tool definitions, execution state |
| Capability policy | Security architecture | Policy model, default-deny rules, risk classes, exception criteria |
| Workload identity | Identity and access management | Attestation, token issuance, federation, revocation, access review |
| Tool broker | Platform engineering | Structured operations, target validation, request enforcement, error handling |
| Network controls | Cloud and network security | Egress gateways, segmentation, DNS controls, destination policy |
| Package broker | Application security or DevSecOps | Artifact approval, scanning, signatures, provenance, caching |
| Monitoring | Security operations and observability teams | Trajectory correlation, detection rules, alerting, evidence retention |
| Human approval workflows | Business and service owners | Risk acceptance for production, data, financial, or customer impact |
| Kill and containment controls | Security operations | Termination, credential revocation, quarantine, incident escalation |
| Recovery and resumption | Service owner and incident commander | Validation, rollback, approval to restart, post-incident actions |
| Governance | AI governance and risk | Risk classification, control evidence, exceptions, audit, review cadence |
Build a dedicated incident classification
Not every agent failure is a cybersecurity incident.
Useful classifications include:
- Model quality failure
- Prompt injection
- Tool authorization failure
- Credential exposure
- Policy enforcement failure
- Network boundary violation
- Data-handling incident
- Unauthorized external interaction
- Production integrity incident
- Agent-enclave escape
- Monitoring or kill-control failure
The classification determines whether the response remains within platform operations or escalates to formal incident command, legal, privacy, compliance, or third-party notification processes.
Preserve the full trajectory
Incident evidence should include:
- Original task
- System and policy instructions
- Retrieved context
- Model and planner outputs
- Tool requests
- Broker transformations
- Policy decisions
- Credentials issued
- Network connections
- Process and file activity
- Human approvals
- Resource changes
- Termination events
- Enclave image and configuration
- Model and tool versions
A list of shell commands is not enough to reconstruct why the system acted.
Test termination before deployment
A kill switch that has never been exercised is an assumption.
Validation should confirm that termination revokes authority across the model, orchestrator, tools, credentials, network paths, pending jobs, and downstream sessions.
Enterprise Adoption Checklist
A zero-trust agent platform should be introduced as an enterprise security capability, not as a collection of optional agent settings.
Scope and risk classification
- Inventory every agent that can invoke tools or change external systems.
- Identify the maximum reachable authority of each complete agentic system.
- Classify agents by data sensitivity, network reach, operational impact, and autonomy.
- Distinguish advisory, read-only, proposed-change, and autonomous-execution workloads.
- Document prohibited use cases and trust-boundary crossings.
Identity and credentials
- Assign a unique identity to every agent execution.
- Bind identities to task, enclave, policy, and lifetime.
- Remove persistent service-account credentials from agent workers.
- Prevent raw secrets from entering prompts, logs, environment variables, or writable files.
- Revoke downstream credentials when the task ends.
- Test identity reuse, role assumption, and token-exchange paths.
Tooling
- Place sensitive tools behind policy-enforcing brokers.
- Authorize individual operations rather than broad tool names.
- Separate read, propose, and execute capabilities.
- Prevent agents from registering tools or changing broker configuration.
- Constrain interpreters, child processes, filesystem paths, and executable loading.
- Record tool input, output, identity, target, and policy decision.
Network
- Apply default-deny ingress and egress.
- Allow only named destinations, protocols, ports, and purposes.
- Separate internal service access from internet access.
- Route outbound traffic through an authenticated egress gateway.
- Restrict DNS and monitor resolution attempts.
- Validate controls at the host, workload, network, and target-service layers.
- Test alternate proxies, IPv6, metadata endpoints, and shared services.
Package and software supply chain
- Remove direct package-repository access from agent workers.
- Use an enterprise retrieval and validation service.
- Pin package versions and immutable digests.
- Verify signatures and provenance where supported.
- Scan dependencies and installation behavior.
- Deliver packages or rebuilt images read-only.
- Separate software creation, signing, publication, and deployment identities.
Runtime budgets
- Set maximum task duration and idle time.
- Limit tool calls, shell operations, retries, processes, and network requests.
- Enforce CPU, memory, storage, bandwidth, and token budgets.
- Fail closed when budgets are exhausted.
- Require new authorization for extensions.
- Prevent automatic restart after security termination.
Approval
- Define human approval triggers based on trust boundaries.
- Display target, identity, data impact, rollback, and rationale.
- Issue approvals for specific operations, not unlimited continuation.
- Prevent self-approval by the requesting agent or owning automation.
- Expire approvals quickly.
- Audit approver identity and decision context.
Monitoring and response
- Correlate objectives, model outputs, tools, identity, process, and network telemetry.
- Detect repeated denied requests and privilege exploration.
- Keep monitoring and policy administration outside the enclave.
- Stream logs to an independently administered evidence store.
- Deploy canary credentials and decoy resources where appropriate.
- Test the kill path and credential revocation process.
- Define incident ownership, severity, containment, and resumption criteria.
- Conduct adversarial testing before production autonomy is enabled.
Conclusion
An autonomous AI agent with shell access, credentials, package installation, tools, and network connectivity is not merely another application process. It is an adaptive workload capable of searching for combinations of authority that static software may never attempt.
The enterprise should therefore secure the agent according to the maximum authority it can exercise, not the narrow task it was assigned.
That means replacing standing access with task-bound capability leases, persistent identities with ephemeral workload identities, exposed credentials with brokered operations, broad connectivity with deny-by-default egress, and unlimited execution with enforceable budgets.
It also means accepting that the model cannot be the final security authority. Prompts can describe the objective, but independent infrastructure must decide whether an action is permitted. Tool brokers, credential services, network controls, approval systems, and target platforms must enforce boundaries the agent cannot rewrite.
The practical goal is not a perfectly obedient model. It is a control system in which a mistaken, manipulated, or unauthorized decision cannot acquire enough authority to become a damaging enterprise action.
The next implementation step is to design an agent execution enclave that combines ephemeral identity, brokered tools, verified package delivery, deny-by-default egress, independent monitoring, and tested termination into one repeatable platform service.
External References
- National Institute of Standards and Technology: SP 800-207, Zero Trust Architecture
Canonical URL: https://csrc.nist.gov/pubs/sp/800/207/final - National Institute of Standards and Technology: SP 800-207A, A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments
Canonical URL: https://csrc.nist.gov/pubs/sp/800/207/a/final - National Institute of Standards and Technology: AI Agent Standards Initiative
Canonical URL: https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative - National Cybersecurity Center of Excellence: Software and AI Agent Identity and Authorization
Canonical URL: https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization - National Institute of Standards and Technology: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
Canonical URL: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence - OWASP Gen AI Security Project: OWASP Top 10 for Agentic Applications for 2026
Canonical URL: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ - SPIFFE: Working with SVIDs
Canonical URL: https://spiffe.io/docs/latest/deploying/svids/ - Open Policy Agent: Open Policy Agent Documentation
Canonical URL: https://www.openpolicyagent.org/docs - Kubernetes: Network Policies
Canonical URL: https://kubernetes.io/docs/concepts/services-networking/network-policies/ - Kubernetes: Jobs
Canonical URL: https://kubernetes.io/docs/concepts/workloads/controllers/job/ - SLSA: About SLSA
Canonical URL: https://slsa.dev/spec/v1.2/about - Sigstore: Sigstore Quickstart with Cosign
Canonical URL: https://docs.sigstore.dev/quickstart/quickstart-cosign/ - MITRE D3FEND: Decoy User Credential
Canonical URL: https://d3fend.mitre.org/technique/d3f%3ADecoyUserCredential/
Introduction GPU sharing is easy to describe and difficult to govern. A platform team can expose one physical accelerator as several scheduler-visible...