Securing AI Agents

What this book helps you do

This book assumes that untrusted data may influence model output and asks a more useful question: what can that influence cause? It designs enforceable boundaries around tool proposals, authorization, short-lived identity, sandboxing, memory, network and filesystem access, effect receipts, and audit trails so model behavior is never the sole security control.

Problems this book helps you solve

• A stronger system prompt is treated as the primary prompt-injection defense.
• The agent inherits broad user or service credentials for every tool call.
• Tool schemas validate parameter shape but not authority or business policy.
• Retrieved content, tool output, and memory can become instructions without trust labels.
• A sandbox restricts code execution but still exposes unrestricted network egress or secrets.
• Operators cannot reconstruct which proposal, policy, credential, and effect produced a change.

Decisions you will be able to make

• Which untrusted inputs can influence the model and which effects could follow.
• How to separate proposal, authorization, execution, persistence, and confirmation.
• What subject, resource, action, parameter, time, and purpose belong in a capability envelope.
• When human approval changes risk and when it only adds approval theater.
• Which sandbox, filesystem, network, secret, and dependency boundaries fit the consequence.
• How memory writes, revocation, incident response, and audit evidence should operate.

Reading path

1. Model the agent systemMap untrusted inputs, model influence, trusted decisions, tools, effects, stores, and operators.
2. Contain prompt injectionReduce exposure while assuming that instruction-like data can still alter model behavior.
3. Mediate tool authorityUse a reference monitor, narrow capabilities, parameter policy, and two-phase effects.
4. Bind identity and delegationIssue short-lived, audience-restricted authority and preserve attributable task intent.
5. Sandbox consequencesChoose isolation, filesystem, egress, secret, image, and dependency controls by impact.
6. Govern memory and auditControl persistence, poisoning, retention, revocation, evidence, and incident response.

Security begins after the model proposes an action

A model can suggest an operation; it should not define its own authority. The system needs an independently governed decision point that evaluates the acting subject, target resource, operation, parameters, time, policy, and accumulated risk.

Design for manipulated output

Prompt injection is one path to unsafe output, but hallucination, stale context, compromised tools, and operator error can produce similar proposals. Controls should contain consequences regardless of why the proposal is wrong.

Use it with

Start with one high-impact workflow and complete the public prompt-injection control matrix. If a row names a prompt as the enforcement mechanism, keep working until an external control owns the decision.

Evidence and method

The book grounds bounded claims in standards and official security guidance while labeling its control graphs and design patterns as author frameworks. It does not claim that any single safeguard prevents prompt injection. Threat examples are synthetic; secure deployment still requires local threat modeling, testing, policy ownership, and incident response.

Read a sample

Signal Studio does not reproduce manuscript chapters on this site. Open the Amazon listing to use Read Sample or Kindle Instant Preview

Resources

Errata and related guidance

Report or review an erratum.

• Can a system prompt stop prompt injection?
• How should an AI agent tool-permission system work?