Security Guide

Security, from the inside out.

An AI agent is a program you have deliberately given the ability to make decisions, call tools, run code, reach the network, and remember things across sessions. That is exactly the power you want — and exactly what an attacker wants to borrow. This guide is the complete map of how the harness keeps that power on a leash: every protocol, where it lives in the code, and what attack it stops.

Read this first: who threatens an agent?

Traditional app security asks "can a malicious user break in?" An agentic system has to ask a harder question: "can malicious content turn my own agent against me?" The agent reads web pages, tool outputs, retrieved documents, and memories — any of which an attacker may have written. The moment the agent treats that text as instructions instead of data, your trusted agent is now working for someone else.

So the harness is built on one uncomfortable assumption: everything the model reads or produces is untrusted until proven otherwise. User input, tool results, model output, retrieved knowledge — all of it passes through checks before it is allowed to cause an effect. That assumption shapes every protocol in this guide.

i
This guide is a sibling to the others

The Developer Guide teaches you the codebase. The Architecture Guide covers Azure deployment (VNets, private endpoints, Key Vault). This guide covers the runtime security protocols inside the harness itself — the code that runs on every turn, regardless of where you host it. The three overlap at the edges, and we cross-link where they do.

Defense in depth: the seven layers

No single control is trusted to be perfect. A request from the outside world has to pass through seven independent layers before it can do anything irreversible, and the agent's output has to pass back out through them. If one layer is bypassed, the next still holds. Read this stack top-to-bottom — it is the spine of the whole guide.

1 · Identity
Who is calling? JWT/Entra on the MCP server, mTLS + JWT for agent-to-agent, role and permission checks, CORS, security headers, rate limiting. → Identity & Access
2 · Autonomy
How much is this agent allowed to do on its own? Restricted / Supervised / Autonomous tiers, the governance pipeline behavior, human-approval escalation. → Autonomy & Governance
3 · Tool Permissions
Which specific tools may it touch? Keyed-DI registration, the three-phase Deny→Ask→Allow resolver, and bypass-immune plugin DeniedTools. → Tools & Permissions
4 · Execution
When a tool actually runs code, it is boxed in. Windows Job Objects / Docker sandboxes, a closed-by-default capability model, and HMAC attestation of results. → Sandbox & Execution
5 · Egress
Where on the network can it reach? A two-ring egress wall — per-skill hostname allowlist plus connect-time IP filtering — stops SSRF and cloud-metadata theft. → Egress & SSRF Defense
6 · Content Safety
What is in the text flowing in and out? Content-safety screening, deterministic prompt-injection scanning, and response sanitization for leaked secrets and exfiltration URLs. → Content Safety
7 · Data & Privacy
What can it see and keep? Per-tenant / per-owner knowledge isolation, provenance stamping, retention/compliance, and right-to-erasure receipts. → Data Protection & Privacy

Sitting underneath all seven is assurance: the OWASP Agentic Top-10 evaluation pack, ten deterministic tests that try to break these layers on every pull request and fail the build if any layer regresses. Layers stop attacks; the eval gate stops you from accidentally removing a layer.

The four principles behind every protocol

If you remember nothing else, remember these. Every specific control in this guide is one of these four ideas applied to a particular layer.

1. Untrusted by default
Model output, tool results, retrieved documents, and user input are all treated as potentially hostile. They are screened, sanitized, or sandboxed before they are allowed to influence a decision or reach the LLM's context.
2. Closed by default
A capability the agent was not explicitly granted is denied. Sandboxes start with no file, network, or subprocess access; the egress wall blocks any host not on an allowlist; tools resolve to Ask unless a rule says Allow.
3. Fail closed
When a control is misconfigured or a check errors, the safe answer is "no." A quorum approval with a broken threshold denies rather than auto-approves; an egress request with no agent identity is refused, not allowed.
4. Defense in depth
No control is a single point of failure. Bypassing one layer lands you in the next. DeniedTools is bypass-immune even for fully autonomous agents; SSRF is blocked by both a hostname allowlist and a connect-time IP filter.

How this guide is organized

Each page covers one layer end-to-end: what it defends against, how it works, the exact classes and files that implement it, and the configuration you control. Pages stand alone, but they read best in order — the layers build on each other the way an attacker would encounter them.

01 ★
Threat Model & Defense in Depth

What makes agentic security different, the attack surface of an autonomous agent, and how the seven layers map to real-world threats. The mental model for everything else.

02
Identity & Access

JWT/Entra auth on the MCP server, agent-to-agent mTLS + token validation, role and permission gating, CORS, HTTP security headers, and per-user rate limiting.

03
Autonomy & Governance

The Restricted / Supervised / Autonomous tiers, the governance pipeline behavior, and multi-party human approval (AllOf / AnyOf / Quorum) with a tamper-evident audit log.

04
Tools & Permissions

Keyed-DI tool registration, the three-phase Deny→Ask→Allow permission resolver, and why a plugin's DeniedTools can never be auto-approved away.

05
Sandbox & Execution

Windows Job Object and Docker sandboxes, the closed-by-default capability model, resource limits, argument-injection prevention, and HMAC attestation of results.

06 ★
Egress & SSRF Defense

The two-ring egress wall: per-skill hostname allowlists plus connect-time IP filtering that blocks private ranges, loopback, link-local, and cloud metadata.

07
Content Safety & Injection

Content-safety screening, deterministic prompt-injection scanning, and response sanitization that redacts leaked credentials and blocks exfiltration URLs.

08
Data Protection & Privacy

Per-tenant and per-owner knowledge isolation, provenance stamping, retention and compliance, right-to-erasure receipts, and secrets handling via Key Vault.

11 ★
Externally-Authored Agents

The one surface that runs an agent the host did not write: capability-envelope confinement resolved from the caller's own credential, hostile-archive guards, ownership binding, and fail-closed startup.

09 ★
OWASP Agentic Evals

Ten deterministic tests mapped to the OWASP Agentic Security Initiative Top 10, run as a CI gate that blocks any pull request that weakens a defense.

10
Security Cheatsheet

The pipeline-behavior order, every security config key, a pre-merge checklist, a glossary, and pointers to the deep-dive reference docs. Bookmark this one.

The page conventions

You will see the same callout colors used throughout. Worth learning once:

Jargon callout

Purple boxes define a security term the first time it appears. Example: SSRF (Server-Side Request Forgery) — tricking your server into making a network request on the attacker's behalf, often to reach an internal address the attacker cannot reach directly.

Attack scenario

Red boxes walk through a concrete attack — what the attacker tries — and then point to the exact control that stops it. These are the most useful boxes for understanding why a protocol exists.

Operator tip

Green boxes are the practical knobs — the config setting to flip, the default to keep, the thing to check before you ship.

!
Heads up

Yellow boxes flag a footgun — a default that looks safe but isn't, or a control that only works if you wire it up correctly.


Ready? Start with the Threat Model — by the end of that page you'll understand what the harness is actually defending against, and the seven layers will click into place.