Agentic AI security is the practice of controlling what an autonomous AI system is allowed to do once it starts acting on its own — which tools it may call, with which arguments, inside which execution boundary, and with which credentials. It differs from model safety. Model safety asks whether the model produces acceptable text. Agentic security asks what happens when that text becomes a command, a payment, a deletion, or an outbound network request.

That difference matters because an agent's output is no longer the end of the pipeline. It is the input to a tool, and tools have real effects. This guide covers the two controls that do the most work in practice — tool-call validation and sandbox isolation — and how they fit into the wider set of layers described in our secure AI infrastructure architecture guide.

Why agents change the threat model

A chatbot with no tools has a narrow blast radius. The worst case is a wrong or offensive answer. An agent with tools inherits every permission those tools hold, and it decides when to use them based on text it has read — text that may have come from a web page, a support ticket, a PDF, or another agent.

Three properties make this hard:

- Instructions and data share one channel. The model reads a retrieved document the same way it reads your system prompt. Anything it reads can attempt to steer it. - Actions compose. A harmless read followed by a harmless write can produce an outcome neither step would be approved for individually. - Autonomy removes the human checkpoint. In multi-step loops, dozens of tool calls happen between prompts, so nobody reviews the middle of the chain.

Guardrails that only inspect prompts and completions cannot close these gaps. Controls have to sit at the point of action.

Tool-call validation: treat every call as untrusted input

Tool-call validation means checking each proposed tool invocation against a policy before it executes, regardless of how confidently the model produced it. The model proposes; the platform decides.

A validation layer that holds up in production does five things.

1. Schema enforcement

Every tool declares a strict schema — field names, types, ranges, enumerations — and calls that fail it are rejected rather than coerced. Rejecting an unparseable call is cheaper than guessing at intent.

2. Argument-level authorisation

Schema validity is not permission. A refund call can be perfectly formed and still exceed the amount the agent may refund, or reference an order belonging to another tenant. Authorisation checks must run against the arguments and the acting identity, not the tool name alone.

3. Least-privilege tool exposure

An agent should see only the tools its current task requires. Narrowing the exposed tool set per task is the single cheapest reduction in blast radius available, and it defends against injection attempts that reference capabilities the agent cannot reach.

4. Effect classification and approval gates

Classify tools by consequence: read-only, reversible write, irreversible write, money movement, credential access. Read-only calls run freely. Irreversible and financial calls require a human approval or a second independent check. Attaching approval to consequence rather than to tool count keeps the workflow usable.

5. Rate and budget policy

Loops fail loudly or quietly, and quiet failures are expensive. Cap calls per task, per minute, and per unit of spend, and halt the run when a cap is hit instead of degrading silently.

Validation also produces the evidence you need later. Every accepted and rejected call, with arguments, identity, policy decision, and outcome, becomes the audit trail an investigator or auditor will ask for.

Sandbox isolation: assume the code will misbehave

Sandbox isolation means running agent-generated code and agent-driven tool execution inside an environment where a compromise cannot reach anything that matters. It is the control that limits damage when validation is bypassed — and you should plan for that, because prompt injection research keeps finding new ways through text-level defences.

Effective isolation combines four boundaries.

Process and kernel boundary. Containers sharing a host kernel are a weak boundary for untrusted code. Micro-VMs or equivalent hardware-assisted virtualisation give each run its own kernel, so a container escape does not become host access.

Filesystem boundary. Mount only what the task needs, read-only where possible, and discard the whole filesystem when the run ends. Ephemeral environments remove persistence, and without persistence an attacker cannot establish a foothold between runs.

Network boundary. Default-deny egress is the highest-value single rule in agent infrastructure. An agent that cannot open arbitrary outbound connections cannot exfiltrate data no matter what it was persuaded to do. Allow-list the specific hosts each task needs, and log every attempt that falls outside the list.

Credential boundary. Long-lived secrets must never be readable inside the sandbox. Issue short-lived, narrowly scoped tokens per run, mint them outside the boundary, and let them expire with the run. If an environment variable inside the sandbox holds a production key, the isolation is decorative.

Verify these boundaries rather than assuming them. A practical test suite attempts to read a file outside the mount, resolve an unlisted hostname, open a raw socket, persist a file between runs, and read a credential it should not hold. Each attempt should fail and should appear in your logs.

How the layers work together

Neither control is sufficient alone. Validation without isolation means a single policy gap becomes a host compromise. Isolation without validation means the agent still performs authorised-looking damage inside its box — wrong refunds, deleted records, leaked data through an allowed channel.

A reasonable order of implementation, cheapest and highest-impact first, is: default-deny egress, least-privilege tool exposure, schema plus argument authorisation, ephemeral execution with per-run credentials, effect-based approval gates, then kernel-level isolation for untrusted code. Observability runs alongside all of them — without traces of tool calls and decisions, you cannot tell whether any layer is actually holding.

Where to go next

For the full seven-layer control model, the reference architecture table, and the vendor questions we use when assessing platforms, read the secure AI infrastructure guide. For the boundary types in more depth, see AI agent isolation, and for the text-level attack path specifically, see prompt injection defence.

VentureGroupAi holds exact-match infrastructure domains for teams building in this category, including RuntimeSecurityAI.com, ProxyGuardAI.com, and SwarmSecurityAI.com, available to buy, lease, or build on.