Deploying secure agentic systems: runtimes and access control for AI agents

Every enterprise wants autonomous agents now. The capability question is largely settled — harnessed models can optimize routes, write code, and manage infrastructure. The question that stalls real deployments is different: what happens when you give one of these systems access to your actual data and your actual APIs?

Because an agent that can read payroll data, execute code, and trigger production APIs is not a productivity tool by default. Without boundaries, it’s the most capable insider threat you’ve ever onboarded — one that works at machine speed and doesn’t know it’s making a mistake.

The HR system for AI

Think about how a new human employee joins your company. Nobody hands them keys to the building and admin access to every server on day one. They get a role. A badge that opens certain doors. System permissions scoped to their department. And their activity happens on monitored infrastructure.

None of that is because you distrust the person. It’s because access control is how organizations stay safe regardless of anyone’s intentions.

Agents need the identical treatment, for a stronger reason: an agent will do exactly what its instructions and its access allow, including combinations nobody anticipated. Onboarding a domain-specific agent means answering the same questions HR answers — what is this worker’s role, which systems does that role justify, who approves an expansion, and how do we revoke everything in one motion when the job ends. If your organization can’t answer those four questions for an agent, the agent isn’t ready to deploy, no matter how well it performs in the demo.

The sandbox: where the agent actually runs

The second control is about blast radius. The largest genuine risk in enterprise agent deployment is data leaving your control — sensitive records routed through third-party APIs you don’t govern, or an agent with network access wandering beyond its task.

That’s why locked-down agent runtimes are becoming standard enterprise architecture: isolated execution environments — on-premise or in your private cloud — where the agent’s compute, network reach, and data access are all explicitly scoped. An agent built to optimize logistics can query the logistics database and nothing else. It can’t browse the source code repository, because the runtime never routed a path to it. The restriction isn’t a policy the agent is asked to follow. It’s a wall it can’t see over.

This is also the data-sovereignty answer. Your proprietary operational knowledge — pricing logic, customer records, source code — is most of what makes a domain-specific agent valuable. Running the model inside infrastructure you control means that knowledge never has to leave the building to be useful.

The part everyone skips: the record

The third control gets the least attention and matters most on the worst day: every action an agent takes must be attributable and logged. Which identity acted, what it did, what data it touched, and what approved it — recorded somewhere the agent itself can’t edit.

This is where agent security stops being a new discipline and starts inheriting an old one. Immutable audit trails, scoped identities, least-privilege access — enterprise security has known these patterns for decades. Agents don’t change the principles. They raise the price of skipping them.

What good looks like

A deployable agent setup, compressed to a checklist: a defined role with enumerated tools and data scopes; an isolated runtime with no implicit network paths; identity-based access evaluated on every call, not granted once at startup; every action logged immutably with a correlation trail; and a revocation path that kills the agent’s access everywhere, at once.

This is also, not coincidentally, the shape of Cortex’s determinism boundary — Policy defines what agents may do, Sandbox defines where they do it, Approvals put humans at the gates, and Audit records all of it. The patterns underneath are ones we’ve maintained as library standards for years: policy-based access in the Iron RBAC, tamper-proof logging in the Audit Vault. Our security posture and practices are documented in the Trust Center.

Questions this paper answers

Why can’t you connect an AI agent directly to enterprise systems?

Because an agent executes whatever its access permits, at machine speed, without knowing when it’s wrong. Direct connection means unbounded actions, potential data leakage through external APIs, and no reliable record of what happened. Boundaries have to be structural, not instructional.

What is a sandboxed runtime for AI agents?

An isolated execution environment — on-premise or private cloud — where an agent’s compute, network reach, and data access are explicitly scoped. The agent physically cannot reach systems outside its mandate, and proprietary data never leaves infrastructure you control.

How do you audit what an AI agent did?

Give every agent a distinct identity, evaluate its permissions on every call, and write every action to an immutable log with who, what, where, when, and a correlation trail. The log must live where the agent can’t modify it.