An engineer argues that their assistant is safe because "it's a language model, and language models just produce text." Why does the chapter treat a personal AI assistant as categorically more dangerous than that framing suggests?
Language models used in assistants are trained on more data, so they hallucinate less and are therefore more trusted
The assistant is an autonomous actor that can call tools, hold credentials, and carry memory, so its words can turn into real-world actions
Assistants run on faster hardware, which lets attackers brute-force them more quickly
Assistants always encrypt their outputs, which ironically hides malicious activity from defenders
Using the book's analogy, why is an agent more like "a personal butler with a key ring" than "a tour guide who can only talk"?
A butler is more polite, so users lower their guard and share more secrets
A tour guide works for a company, while a butler works for an individual, which is the only difference that matters
A talking-only system can at worst give bad output, but a system that can act on the world can be tricked into taking real, harmful actions
A butler never makes mistakes, so any error must be an attack
Why does reading inbound messages from strangers fundamentally break the traditional software security model?
Inbound messages are usually larger than the model's context window, causing overflow errors
The model merges system prompt, retrieved content, and memory into one token stream and cannot reliably tell instructions from data, dissolving the trusted-code / untrusted-input wall
Strangers can only send plain text, which the model refuses to process for safety reasons
Inbound messages are encrypted end-to-end, so the assistant cannot validate them
Two assistants ingest the exact same poisoned document. One can only generate text; the other can send email and run code. What does this contrast illustrate about assessing risk?
The poisoned document is more effective against the text-only bot because it has fewer defenses
Risk is identical in both cases because the same malicious content was used
Blast radius scales with the agent's tools and credentials, so the identical attack is trivial for one and devastating for the other
The tool-using agent is safer because it has more code paths to catch the attack
You are asked to give the "first step" in judging how risky a particular assistant is. Based on the chapter, what should that first step be?
Measure the model's benchmark accuracy on question-answering tasks
Inventory the assistant's blast radius — everything its tools and credentials can touch
Count how many users have talked to the assistant this month
Confirm the assistant uses a paid, closed-source model rather than an open one
What Makes an AI Assistant a Security Target
Key Points
- A personal AI assistant is an autonomous actor — an AI agent that reads external content, chains tool calls, and acts in the world — not merely a text generator.
- Three properties make it powerful and dangerous: tools (functions that touch the real world), credentials (the operator's own secrets), and memory (state across turns).
- Assistants that read inbound messages from strangers dissolve the traditional wall between trusted code and untrusted input; the model cannot reliably tell instructions from data.
- Blast radius is everything the agent's tools and credentials can touch — files, shell, APIs, money, messages — and it determines whether an attack is a nuisance or a catastrophe.
- Mapping blast radius is the first step in assessing an assistant's risk.
A traditional chatbot is, at its core, a text generator: you type something, it produces words back, and the conversation ends there. A personal AI assistant is categorically different. It is an AI agent: a system that can autonomously read external content, chain together multiple tool calls, and take actions in the world with less human oversight at each step. In other words, it is an autonomous actor, not merely a text producer.
Three properties make this actor powerful — and dangerous:
- Tools. The agent can call functions that touch the real world: send an email, run a shell command, query a database, fetch a web page, or move money.
- Credentials. To use those tools, the agent holds secrets — API keys, OAuth tokens, passwords — often the operator's own.
- Memory. The agent carries state across turns and sessions, remembering prior instructions, retrieved documents, and context.
Consider the analogy of a chatbot as a tour guide who can only talk, versus an agent as a personal butler with a key ring. The tour guide can give bad directions, which is annoying but contained. The butler can be tricked into unlocking the wrong door. When a system "can browse, retrieve, write, or execute, even tiny embedded instructions can become real exploits." The capability that makes an assistant useful is precisely the capability that makes it worth attacking.
Visual animation — coming soon
Reading inbound messages from strangers vs. trusted-only interfaces
The second defining trait of a personal assistant is who it listens to. Many assistants are designed to read inbound messages — emails, chat messages, issue comments, webhook payloads — that arrive from outside the operator's trust circle. The moment your assistant summarizes an email from a stranger, that stranger's words enter the assistant's reasoning process.
This is a profound shift from traditional software. In a conventional program, there is a clear separation between trusted code (written by the developer) and untrusted input (typed by a user), and the code decides how to handle the input. AI systems eliminate this boundary by design: they merge the system prompt, retrieved documents, tool descriptions, and memory into a single token stream, and the model "cannot reliably distinguish which text represents instructions versus data." As one analysis puts it: "The attacker never talks to the model. They poison the data the model will later read."
Blast radius: what an assistant can touch
Security professionals use the term blast radius to describe how much damage results if a given component is compromised. For an AI assistant, the blast radius is defined by everything its tools and credentials can touch: local files, a shell, external APIs, payment systems, and outbound messages. The same malicious content produces wildly different outcomes depending on the agent's reach:
| Scenario | Agent capabilities | Result of a poisoned document |
|---|
| Simple chatbot | Text generation only | Produces misleading text — "inconvenient but contained" |
| Tool-using agent | Can send email, execute code | May "trigger email sending, code execution, or credential harvesting" |
The lesson is that you cannot reason about an assistant's risk without first inventorying its blast radius. An assistant that can only draft text is a modest target; the same assistant, once granted the ability to send email, run shell commands, or authorize a transfer, becomes a high-value one — because "a small instruction in untrusted content can trigger meaningful actions."
Visual animation — coming soon
An engineer argues that their assistant is safe because "it's a language model, and language models just produce text." Why does the chapter treat a personal AI assistant as categorically more dangerous than that framing suggests?
Language models used in assistants are trained on more data, so they hallucinate less and are therefore more trusted
The assistant is an autonomous actor that can call tools, hold credentials, and carry memory, so its words can turn into real-world actions
Assistants run on faster hardware, which lets attackers brute-force them more quickly
Assistants always encrypt their outputs, which ironically hides malicious activity from defenders
Using the book's analogy, why is an agent more like "a personal butler with a key ring" than "a tour guide who can only talk"?
A butler is more polite, so users lower their guard and share more secrets
A tour guide works for a company, while a butler works for an individual, which is the only difference that matters
A talking-only system can at worst give bad output, but a system that can act on the world can be tricked into taking real, harmful actions
A butler never makes mistakes, so any error must be an attack
Why does reading inbound messages from strangers fundamentally break the traditional software security model?
Inbound messages are usually larger than the model's context window, causing overflow errors
The model merges system prompt, retrieved content, and memory into one token stream and cannot reliably tell instructions from data, dissolving the trusted-code / untrusted-input wall
Strangers can only send plain text, which the model refuses to process for safety reasons
Inbound messages are encrypted end-to-end, so the assistant cannot validate them
Two assistants ingest the exact same poisoned document. One can only generate text; the other can send email and run code. What does this contrast illustrate about assessing risk?
The poisoned document is more effective against the text-only bot because it has fewer defenses
Risk is identical in both cases because the same malicious content was used
Blast radius scales with the agent's tools and credentials, so the identical attack is trivial for one and devastating for the other
The tool-using agent is safer because it has more code paths to catch the attack
You are asked to give the "first step" in judging how risky a particular assistant is. Based on the chapter, what should that first step be?
Measure the model's benchmark accuracy on question-answering tasks
Inventory the assistant's blast radius — everything its tools and credentials can touch
Count how many users have talked to the assistant this month
Confirm the assistant uses a paid, closed-source model rather than an open one
What made EchoLeak (CVE-2025-32711) a landmark incident rather than just another proof-of-concept?
It was the first time a model refused to answer a question, exposing a denial-of-service risk
It was the first documented case of prompt injection weaponized for concrete data exfiltration in a production AI system
It proved that closed-source models are always safer than open-source ones
It was the first vulnerability ever assigned a CVE identifier
Why is the "zero-click" nature of EchoLeak especially significant for defenders?
It means the exploit only worked once and could not be repeated
It means the attack required physical access to the victim's machine
The victim never had to click a link or open an attachment — merely having Copilot process a crafted email was enough to trigger exfiltration
It means no data actually left the organization, only internal logs were touched
The chapter identifies three recurring root causes across real incidents. Which set correctly names them?
Weak passwords, unpatched servers, and phishing
Over-trust of input, over-privilege, and missing isolation
Slow hardware, small context windows, and outdated training data
Poor UI design, missing documentation, and lack of user training
The chapter says most breaches stem from architectural failures, and that "strong prompts alone cannot solve indirect prompt injection." What is the practical implication of calling these failures architectural?
They can be fixed by writing a more carefully worded system prompt
They address the symptom rather than the structural problem, so defenses must be built into the system's structure, not just its wording
They only affect enterprise systems, never personal ones
They are impossible to defend against, so no controls are worth building
Why does the chapter argue that "it's just my personal bot" is a dangerous assumption rather than a comforting one?
Personal bots are legally required to meet the same standards as enterprise systems
Personal bots are always built on weaker models that attackers prefer
Attacks need only a clever prompt, incidents are doubling year over year, and personal deployments wire the agent straight to the operator's real money and data with the least oversight
Personal bots cannot be patched, so any flaw is permanent
Lessons From Real Incidents
Key Points
- EchoLeak (CVE-2025-32711, CVSS 9.3) in Microsoft 365 Copilot was the first documented case of prompt injection weaponized for real data exfiltration in a production system.
- EchoLeak required zero clicks: a single crafted email caused Copilot to harvest internal files and exfiltrate them via a trusted domain (Teams).
- The attack unfolded in six stages — delivery, indirect injection, context manipulation, data harvesting, exfiltration, and payload optimization — and became a template for a whole class of incidents (Shadow Escape, cooperating coding assistants, leaked one-time passwords, zero-click RCE).
- Three architectural root causes recur: over-trust of input, over-privilege, and missing isolation — mapping to OWASP LLM01 (Prompt Injection) and LLM06 (Excessive Agency).
- Incidents have doubled since 2024, 35% were caused by simple prompts, and 88% of agent-deploying organizations report incidents — so "it's just my personal bot" is itself a vulnerability.
The landmark case is EchoLeak (tracked as CVE-2025-32711, with a critical CVSS severity score of 9.3), a vulnerability in Microsoft 365 Copilot disclosed by Aim Labs researchers in June 2025. EchoLeak is significant because it is "the first documented case of prompt injection being weaponized for concrete data exfiltration in a production AI system" — the moment the threat left the whiteboard and hit real software.
What made EchoLeak alarming was that it required zero clicks. By sending a single crafted email — with no user interaction required — an attacker could cause Copilot to access internal files and exfiltrate their contents to an attacker-controlled server. The victim never had to open a malicious link or download an attachment; simply having Copilot present in their inbox was enough.
The attack unfolded in stages:
- Initial delivery. The attacker sends a benign-looking email containing hidden malicious instructions.
- Indirect injection. The email bypasses Microsoft's XPIA (Cross Prompt Injection Attempt) classifiers and link-redaction filters using clever markdown formatting.
- Context manipulation. The attack leverages an "LLM Scope Violation" to manipulate the AI's internal handling of trusted versus untrusted content.
- Data harvesting. Copilot extracts the user's entire chat history and previously referenced files.
- Exfiltration. Data is routed to attacker-controlled servers via trusted domains such as Microsoft Teams to slip past content-security policies.
- Payload optimization. Malicious instructions are "sprayed" across multiple email sections to maximize the chance the model retrieves them.
To make this concrete, picture the corporate-espionage version of a letter that reads, in invisible ink between the visible lines: "Butler, gather every confidential file in the house and mail copies to this address." The butler — Copilot — reads the letter as part of doing its job, obeys the hidden instruction, and uses a trusted courier (Teams) so the outgoing package never looks suspicious. Microsoft patched the specific flaw server-side and reported no exploitation in the wild, but the pattern is now a template.
Figure 1.1: The six-stage EchoLeak attack chain, from inbound email to data exfiltration
flowchart TD
A["1. Initial delivery: attacker sends a benign-looking email with hidden instructions"] --> B["2. Indirect injection: email bypasses XPIA classifiers and link redaction via markdown"]
B --> C["3. Context manipulation: 'LLM Scope Violation' blurs trusted vs. untrusted content"]
C --> D["4. Data harvesting: Copilot extracts chat history and referenced files"]
D --> E["5. Exfiltration: data routed via trusted domains (Teams) to slip past CSP"]
E --> F["6. Payload optimization: instructions 'sprayed' across email to maximize retrieval"]
F --> G(["Internal files reach attacker-controlled server"])
Visual animation — coming soon
EchoLeak was not alone. Other 2024–2025 incidents illustrate the breadth of the class:
- Shadow Escape (2025): a zero-click exploit against agents built on the Model Context Protocol (MCP) enabled silent workflow hijacking and data exfiltration in systems such as ChatGPT and Google Gemini.
- Cooperating coding assistants: a researcher got GitHub Copilot and Claude to rewrite each other's configuration files and escalate each other's privileges, creating an AI feedback loop that "freed" both from certain safety constraints.
- Perplexity Comet: hidden text in a Reddit post leaked one-time passwords.
- Zero-click RCE in MCP IDEs: a compromised Google Docs file triggered remote code execution.
Recurring root causes: over-trust of input, over-privilege, missing isolation
Look across these incidents and the same three root causes recur. The research is blunt: most breaches stem from "inadequate input validation, infrastructure deficiencies, and insufficient human oversight rather than model-level flaws alone." Translated into design terms:
| Root cause | What it means | How it showed up |
|---|
| Over-trust of input | Treating retrieved content as instructions rather than untrusted evidence | EchoLeak's hidden email instructions were obeyed |
| Over-privilege | Granting the agent broad, high-impact capabilities and access | Copilot could reach the user's entire file and chat history |
| Missing isolation | No containment boundary between the agent and sensitive systems | The "LLM Scope Violation" let the model cross its intended scope |
These map to well-known industry categories. The OWASP Top 10 for LLM Applications 2025 leads with LLM01 — Prompt Injection, describing attackers crafting input the model "interpret[s] as new instructions rather than content to process, exploiting the lack of separation between instructions and data." It also names LLM06 — Excessive Agency, where agents "with overly broad tool access, excessive permissions, or high-impact actions without human approval become exploitable attack surfaces" — the formal name for over-privilege. The important insight is that these are architectural failures: "strong prompts alone cannot solve indirect prompt injection because they address the symptom, not the structural problem."
Why "it's just my personal bot" is a dangerous assumption
A tempting rationalization is that these headlines involve enterprise giants like Microsoft, and that a hobbyist's personal assistant is too small to matter. The data says otherwise. AI security incidents have doubled since 2024, and 2025 is set to surpass all prior years combined in breach volume. Strikingly, 35% of all real-world AI security incidents were caused by simple prompts, and "some led to $100K+ in real losses without writing a single line of code." The barrier to attacking an AI assistant is a well-phrased sentence, not a sophisticated exploit chain — which means small and personal is no protection.
Scale reinforces the point: 88% of organizations deploying AI agents have experienced confirmed or suspected security incidents, yet only 14.4% of those agents reached production with full security and IT approval. A personal bot is often more exposed, not less: it wires the assistant directly to the operator's real accounts, real money, and real files, frequently with none of the review an enterprise deployment receives. The blast radius is personal, and so is the loss.
Visual animation — coming soon
What made EchoLeak (CVE-2025-32711) a landmark incident rather than just another proof-of-concept?
It was the first time a model refused to answer a question, exposing a denial-of-service risk
It was the first documented case of prompt injection weaponized for concrete data exfiltration in a production AI system
It proved that closed-source models are always safer than open-source ones
It was the first vulnerability ever assigned a CVE identifier
Why is the "zero-click" nature of EchoLeak especially significant for defenders?
It means the exploit only worked once and could not be repeated
It means the attack required physical access to the victim's machine
The victim never had to click a link or open an attachment — merely having Copilot process a crafted email was enough to trigger exfiltration
It means no data actually left the organization, only internal logs were touched
The chapter identifies three recurring root causes across real incidents. Which set correctly names them?
Weak passwords, unpatched servers, and phishing
Over-trust of input, over-privilege, and missing isolation
Slow hardware, small context windows, and outdated training data
Poor UI design, missing documentation, and lack of user training
The chapter says most breaches stem from architectural failures, and that "strong prompts alone cannot solve indirect prompt injection." What is the practical implication of calling these failures architectural?
They can be fixed by writing a more carefully worded system prompt
They address the symptom rather than the structural problem, so defenses must be built into the system's structure, not just its wording
They only affect enterprise systems, never personal ones
They are impossible to defend against, so no controls are worth building
Why does the chapter argue that "it's just my personal bot" is a dangerous assumption rather than a comforting one?
Personal bots are legally required to meet the same standards as enterprise systems
Personal bots are always built on weaker models that attackers prefer
Attacks need only a clever prompt, incidents are doubling year over year, and personal deployments wire the agent straight to the operator's real money and data with the least oversight
Personal bots cannot be patched, so any flaw is permanent
Which list correctly enumerates the seven threat pillars the book uses to structure agent defense?
Firewall, antivirus, encryption, backups, passwords, patching, and training
Injection, identity, sandboxing, secrets, supply chain, confused deputy, and audit
Speed, accuracy, cost, latency, memory, throughput, and uptime
Input, output, model, prompt, context, tool, and response
The chapter says the pillars "are not a menu to pick from" but form a dependency chain. Why is injection placed first?
Injection is the easiest pillar to implement, so it is done first for convenience
Injection attacks are the rarest, so eliminating them early clears the field
If untrusted content can rewrite the agent's goals, every later control is operating on corrupted intent
Injection is the only pillar backed by an OWASP category, so it must come first
The chapter states that isolation is "the boundary that makes least privilege enforceable." What does this dependency mean in practice?
Least privilege makes sandboxing unnecessary, so the two are interchangeable
Without a containment boundary you cannot actually bound the blast radius, so least-privilege intentions have nothing to enforce them
Isolation is only about performance, not security
Least privilege must be fully solved before any isolation can be attempted
Why does audit come last in the dependency order rather than first?
Auditing is optional and only needed for compliance paperwork
Logging is how you detect and reconstruct failures of the layers above it, so it sits on top of them
Audit logs are the easiest attack surface, so they are deprioritized
Audit only matters after an agent is decommissioned
An assistant summarizes a stranger's email and then calls a tool to send a reply. Using the four trust zones, where must the two checkpoints go?
Sanitize input where the outside world crosses into the agent; check authorization where the agent crosses into a tool
Only one checkpoint is needed, at the operator boundary, since the operator is fully trusted
Checkpoints belong inside the model itself, because the model is the security perimeter
No checkpoints are needed if the email sender is a known contact
A Layered Threat Model for Agents
Key Points
- A threat model is a structured map of what you are defending against and in what order; the book uses seven pillars.
- The seven pillars are injection, identity, sandboxing, secrets, supply chain, confused deputy, and audit, grounded in the OWASP Top 10 for LLM Applications and the OWASP Top 10 for Agentic Applications.
- The pillars form a dependency chain: injection undermines everything downstream, identity gates trust, isolation makes least privilege enforceable, and audit lets you catch failures in the layers above.
- The unifying concept is the trust boundary — the line where trust changes and data must be re-verified across four zones: operator, agent, tools, and the untrusted outside world.
- AI systems dangerously collapse the boundary between the outside world and the agent's instructions, so "the security perimeter is no longer the model — it is everything around it."
To defend an assistant systematically, you need a threat model — a structured map of what you are defending against and in what order. This book organizes agent security into seven pillars that build on one another.
| # | Pillar | Core question it answers |
|---|
| 1 | Injection | Can untrusted content hijack the agent's instructions? |
| 2 | Identity | Do we know who is talking to the agent? |
| 3 | Sandboxing | Is the agent's execution isolated from the host? |
| 4 | Secrets | Are credentials stored and scoped safely? |
| 5 | Supply chain | Can we trust the skills and dependencies we install? |
| 6 | Confused deputy | Are privileged actions tied to the true requester's authority? |
| 7 | Audit | Can we reconstruct what the agent did and why? |
These pillars are grounded in industry taxonomies. The OWASP Top 10 for LLM Applications 2025 supplies the foundation — prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, and excessive agency among them. The newer OWASP Top 10 for Agentic Applications 2026, released December 9, 2025 and developed with over 100 industry experts, extends these with threats unique to agents that "plan, act, and make decisions across complex workflows": agent goal hijacking, tool misuse, memory and context poisoning, uncontrolled autonomy, delegated identity abuse, and cross-agent prompt injection. As OWASP notes, "these risks don't exist in simple chatbots."
Why the pillars build on each other in dependency order
The pillars are not a menu to pick from; they form a dependency chain, and their order matters. The OWASP agentic threats taxonomy organizes risk in a dependency order across five dimensions: Agent Design → Agent Memory → Planning & Autonomy → Tool Use → Deployment & Operations. Later stages inherit the weaknesses of earlier ones. The book's seven pillars follow the same logic:
- Injection first, because if untrusted content can rewrite the agent's goals, every later control is operating on corrupted intent.
- Identity next, because knowing who is talking lets you decide whose instructions to trust at all.
- Sandboxing and least privilege then matter because "isolation [is] the boundary that makes least privilege enforceable" — you cannot bound the blast radius without containment.
- Secrets and supply chain protect the credentials and code the sandboxed agent relies on.
- Confused deputy defenses ensure that even a correctly-identified, sandboxed agent doesn't lend its authority to the wrong requester.
- Audit comes last because logging is how you detect and reconstruct any failure of the layers above it.
Figure 1.2: The seven pillars in dependency order, each layer building on the ones before it
graph TD
P1["Pillar 1: Injection — can untrusted content hijack instructions?"] --> P2["Pillar 2: Identity — do we know who is talking?"]
P2 --> P3["Pillar 3: Sandboxing — is execution isolated from the host?"]
P3 --> P4["Pillar 4: Secrets — are credentials scoped safely?"]
P3 --> P5["Pillar 5: Supply chain — can we trust installed skills and dependencies?"]
P4 --> P6["Pillar 6: Confused deputy — are privileged actions tied to the true requester?"]
P5 --> P6
P6 --> P7["Pillar 7: Audit — can we reconstruct what the agent did and why?"]
Think of it as building a bank: you decide who may enter (identity) before you build the vault (sandbox), you protect the keys (secrets) before you trust the contractors who built the door (supply chain), and you install cameras (audit) to watch all of it. Skipping an early layer weakens every layer that follows, which is why "effective mitigation must operate outside the model" as a coordinated stack rather than a single control.
Visual animation — coming soon
Trust boundaries: operator, agent, tools, and the outside world
The unifying concept beneath all seven pillars is the trust boundary — the line across which the level of trust changes and data must be treated with suspicion. A personal assistant has four principal zones of trust:
| Zone | Trust level | Role |
|---|
| Operator | Fully trusted | The human owner whose intent should govern the agent |
| Agent | Delegated trust | Acts on the operator's behalf, holding their credentials |
| Tools | Scoped trust | Perform specific actions with real-world effects |
| Outside world | Untrusted | Senders of inbound messages, retrieved documents, third-party content |
The central failure of AI systems is that they collapse the boundary between the outside world and the agent's own instructions. As the research explains, "traditional software maintains clear separation between trusted code and untrusted user input. AI systems eliminate this boundary by design," so when a malicious instruction appears anywhere in the stream, "the system's security perimeter dissolves." The critical reframing is this: "The security perimeter is no longer the model — it is everything around it (the tools, data sources, and orchestration)."
The practical takeaway for a designer is to draw these boundaries explicitly and, at each crossing, ask: what trust is changing here, and what should I re-verify? Every crossing from the untrusted outside world into the agent is a place to sanitize input; every crossing from the agent to a tool is a place to check authorization.
Figure 1.3: The four trust zones with checkpoints at each boundary crossing
flowchart LR
OW["Outside world (untrusted): inbound messages, retrieved documents, third-party content"] -->|"Checkpoint: sanitize input"| AG["Agent (delegated trust): acts on operator's behalf, holds credentials"]
OP["Operator (fully trusted): human owner whose intent governs the agent"] --> AG
AG -->|"Checkpoint: check authorization"| TL["Tools (scoped trust): perform specific real-world actions"]
Visual animation — coming soon
Which list correctly enumerates the seven threat pillars the book uses to structure agent defense?
Firewall, antivirus, encryption, backups, passwords, patching, and training
Injection, identity, sandboxing, secrets, supply chain, confused deputy, and audit
Speed, accuracy, cost, latency, memory, throughput, and uptime
Input, output, model, prompt, context, tool, and response
The chapter says the pillars "are not a menu to pick from" but form a dependency chain. Why is injection placed first?
Injection is the easiest pillar to implement, so it is done first for convenience
Injection attacks are the rarest, so eliminating them early clears the field
If untrusted content can rewrite the agent's goals, every later control is operating on corrupted intent
Injection is the only pillar backed by an OWASP category, so it must come first
The chapter states that isolation is "the boundary that makes least privilege enforceable." What does this dependency mean in practice?
Least privilege makes sandboxing unnecessary, so the two are interchangeable
Without a containment boundary you cannot actually bound the blast radius, so least-privilege intentions have nothing to enforce them
Isolation is only about performance, not security
Least privilege must be fully solved before any isolation can be attempted
Why does audit come last in the dependency order rather than first?
Auditing is optional and only needed for compliance paperwork
Logging is how you detect and reconstruct failures of the layers above it, so it sits on top of them
Audit logs are the easiest attack surface, so they are deprioritized
Audit only matters after an agent is decommissioned
An assistant summarizes a stranger's email and then calls a tool to send a reply. Using the four trust zones, where must the two checkpoints go?
Sanitize input where the outside world crosses into the agent; check authorization where the agent crosses into a tool
Only one checkpoint is needed, at the operator boundary, since the operator is fully trusted
Checkpoints belong inside the model itself, because the model is the security perimeter
No checkpoints are needed if the email sender is a known contact