In one sentence: the AI agent works inside a fenced yard — it can only use the tools
we hand it (mostly read-only), it can only reach approved destinations on the network, every model call passes a safety
filter, it runs on a timer and a budget, and every action it takes is logged and cost-attributed.
The everyday analogy
Think of a contractor you let into the building with an escort and a checklist. They can't wander
anywhere — they go through specific doors (the tools we give them), they can only take the actions on the checklist,
a supervisor watches for anything off-policy, there's a hard stop time, and the sign-in sheet records everything they
touched. The AI agent is that escorted contractor, not a key-holder with the run of the place.
The layers that box the agent in
- 1. It only has the tools we give it. The agent can't run arbitrary code. It gets a small, named set of tools
— for the audits, those are all reads (
list files, read a file,
read deployed state). It has no tool that changes the thing it's inspecting.
- 2. Every model call passes a guardrail. Each request to the AI model goes through a Bedrock guardrail
that blocks disallowed content (PII leakage, off-policy topics) in both directions — what goes in and what comes out.
- 3. It lives in a fenced network. The agent's compute runs in an inspected zone whose firewall only allows a
short list of destinations (approved systems of record). It can't quietly phone home to somewhere it shouldn't.
- 4. Its instructions are fenced too. The operator-authored guidance the agent reads (the grounding docs) is
wrapped so it can steer the task but can't smuggle in commands that override the platform's own rules —
the defense against "prompt injection."
- 5. It runs on a timer and a budget. Every run has a deadline and a token cap. It can't loop forever or quietly
spend without limit; when it nears the deadline it's forced to wrap up.
- 6. Everything is written down. Each model call emits a
*-complete log line with the user, model,
tokens, and duration — so every action is cost-attributed and auditable in the obs Cartridges tab. Nothing the
agent does is invisible.
What a run looks like from the outside
who is asking?
├─ a signed-in person → their Cognito login + group
└─ a scheduled job → a Console MCP machine key (see "How the MCP is secure")
│
▼
the agent loop ──uses──▶ a fixed set of TOOLS (audits: read-only)
│ every model call → guardrail → allowed content only
│ runs in the fenced network zone (approved egress only)
▼
deadline + token budget → forced summary, never runaway
│
▼
result + a *-complete log line (user, model, tokens, duration → cost)
What could go wrong — and why it's contained
| Worry | Why it's contained |
|---|
| "The AI decides to change or delete something." | It has no write/delete tool for what it audits. Capability, not trust, is the limit. |
| "A malicious file tricks the AI into leaking data." | The guardrail filters model output; the network fence blocks unapproved destinations; grounding is fenced so injected text can't override controls. |
| "It runs forever and burns budget." | Hard deadline + token cap per run; it's forced to finish. |
| "Nobody knows what it did." | Every call is logged and cost-attributed in obs. |
The bottom line
The agent is powerful inside its yard and unable to act outside it. It reads what it's allowed to read, over an
approved network, under a filter, on a timer, with a receipt for every action.
The engineering detail lives in the shared agent runtime (
shared/modules/agent/*,
docs/agent-runtime.md) and the model doctrines in
Doctrine section 6
(guardrails, inference profiles, cost attribution). This page is the plain-language version.