Skip to content
Prompt Injection & Tool SafetyArchitectural mitigations

Lead · Core path · 7 chapters

Architectural mitigations

Least-privilege tools, no ambient authority, human confirmation for consequential actions, quarantine patterns, capability-based design

These constraints limit blast radius when prompt-level defenses fail; without them, one injected turn can convert a narrow task into an account-wide incident.

Read these first

What you will know

  • Design an agent with no ambient authority

    Use separate identities and explicit deny-by-default permissions so a compromised turn cannot reach unrelated data, networks, or secrets.

  • Add a human confirmation gate at the right point, not everywhere

    Place approval after the agent has resolved the target and parameters but before an irreversible side effect, or users will approve blindly.

  • Implement a quarantine pattern where untrusted content never reaches a privileged context

    Treat retrieved documents and tool output as attacker-controlled data, keeping them out of prompts or channels that can authorize privileged actions.

  • Give each tool the narrowest capability that still works

    Scope credentials by resource, operation, and lifetime to prevent a tool from becoming a confused deputy with reusable broad access.

  • Review a design and name the privilege to remove

    Trace a realistic injection path through every tool and identity, then verify the workflow still succeeds after the first unnecessary permission is revoked.


Chapters

  1. 1

    Ambient authority

    A pod whose service account reads exactly one bucket satisfies least privilege and still has ambient authority, because the permission is attached to the environment rather than to the request. This chapter separates the two principles — how much authority exists at all, against how it is acquired for an action — and shows the read path where a credential minted for one customer turns an injected read of another customer's file into a denial with the task's name attached to it.

  2. 2

    Request-scoped credentials

    Deriving authority from the task means one identity per trust boundary rather than per codebase, a manifest in which an undeclared tool gets no credentials at all, and a broker outside the agent process that exchanges a signed task ticket for short-lived credentials. You will learn what each part holds in place, what the exchange costs in latency and in role inventory, and why the audit line naming which task acted is a thing a shared service account cannot produce.

  3. 3

    Operation, resource and lifetime scoping

    A tool becomes a confused deputy when it holds a credential broader than its job, and an egress proxy that attaches secrets by hostname builds one out of any general HTTP tool. The awkward case is a vendor that issues only full-access API keys: the answer is a small service of your own that holds the key and exposes the single operation, so the agent's capability is what you permit rather than what the vendor sells. Expect to think about expiry and resource scoping as much as about operations.

  4. 4

    Placing a confirmation gate

    A deployment assistant that opens pull requests, merges and rolls out gets one gate, and merging is the tempting place because it feels final. It is reversible; the rollout, having run forward-only migrations and served traffic, is not. Placed correctly the prompt names the resolved digest, the migration list and the manifest diff, rendered by your own code rather than narrated by the model. The chapter also reads a 1.4-second median time-to-approve as a rate problem and defines the envelope that fixes it.

  5. 5

    The dual-LLM quarantine pattern

    The pattern splits the work in two: one call reads the supplier PDF and emits a constrained result, a second call holds the purchase-order tools and never sees the PDF text. Validating that result against a schema is necessary and not sufficient, because a string field validates perfectly while carrying arbitrary attacker prose across. What holds the boundary is content constraint — enums, ranged numbers, dates, ids resolved against your own records — and a written inventory of the holes you kept.

  6. 6

    Re-classifying untrusted values downstream

    Some crossing values cannot be content-constrained: a free-text notes column that buyers read has to carry prose by design. Passing through a quarantine is not an operation on the data, so the value stays attacker-controlled and must be re-classified as untrusted wherever it lands next — a human's screen, another agent's context, a knowledge-base index, an export — with the label carried in storage as well as in the type. It also covers the attack a correct quarantine leaves standing: choosing among values that are each individually valid.

  7. 7

    Ranking capabilities in a design review

    Given one design review slot for an agent that reads a support inbox and the customer database, writes CRM notes, emails any address, and refunds up to fifty euros, the refunds API draws the eye because it costs money. It is bounded by an amount, a rate and a reconciliation that already runs daily. Free choice of recipient is the unbounded capability, and it converts every read into an outbound channel. Here you learn the ranking, the resolved-set replacement to offer, and what stays unfixed.

External resources