Agency cuts both ways: a new layer secures the agents themselves: sandboxes, policy engines, gateways, guardrails and pre-action authorization between an agent and your infrastructure. Grouped by control-plane layer, top-to-bottom: firewall → guardrails → gateway → authz → policy → sandbox.
Bedrock agents, vendor-side guardrails for content filtering, PII redaction, denied topics, sensitive-info policies. Applied to model + agent tool calls at the platform.
Multi-provider LLM gateway with observability, cost controls, guardrails, PII redaction, semantic caching. Used by agent teams to route + govern hundreds of models behind a single endpoint.
Any agent action, Rego policies evaluate the proposed call before it fires. The de-facto CNCF policy engine, widely adopted for k8s + microservices; agents plug in via sidecar or in-process.
Agents execute predefined Action Types (e.g. order inventory, approve schedule) with the same security and compliance guardrails a human user has. Deterministic tools (mathematical, simulation, optimisation algorithms) wire in as verifiable steps that complement probabilistic LLM reasoning. Ontology MCP extends the same guardrails to external frameworks.
Firewall, guardrails, gateway, authz, policy, sandbox: the stack that governs the agent
Accountability cannot be delegated to a model. Every deployed agent needs a named human owner, and the controls that hold up are the deterministic ones, sandboxes and gates, rather than instructions in a prompt asking the agent to behave.
Show more ▾
None of these layers trusts the model to restrain itself. The model proposes; the control plane disposes. That is why the strongest pattern across the whole security section is the same one that shows up in the incident log: never expose raw secrets or unbounded permissions to the model, and cap the blast radius in the deterministic path instead of trusting a per-call approval the model can talk its way around. Every vendor below is grouped by which layer of that stack it occupies, and each row is sourced.
How do you control what an AI agent is allowed to do?
With controls outside the model, not instructions inside it. The usual stack is a runtime firewall, guardrails near the model, a gateway every model and tool call passes through, a permission check before an action fires, a policy engine and a sandbox around the whole thing. Each layer shrinks what a bad action can reach.
What is an AI guardrail?
A guardrail is a filter on what goes into or comes out of the model: blocking injection attempts, harmful content, or data that should not leave. Most model vendors ship their own. OWASP ranks prompt injection as the top risk for LLM applications, and that is largely what guardrails are trying to catch (OWASP).
What is an AI gateway?
A single point that every model and tool call passes through, where it can be logged, rate-limited, filtered and checked against policy. It gives you one place to see and control traffic instead of each integration enforcing its own rules. It is also where you swap models without rewriting the agent.
What is an agent sandbox?
An isolated environment, with its own filesystem, network and process limits, that the agent runs inside so a compromised run cannot reach the wider system. It caps what code execution, file access and tool use can touch. It is the last line when everything earlier has failed.
Can you just tell an agent in its prompt not to do something?
Not reliably. A prompt instruction is a request, and prompt injection works precisely by getting the model to follow different instructions instead. The controls that hold are deterministic: a permission check in code, a sandbox boundary, a gate the model cannot argue past. The NIST AI Risk Management Framework treats this as governance you build around the system, not a property of the model (NIST).