AI agent security: reduce the blast radius
A practical security baseline for AI systems that read untrusted content and can call tools.
An AI system becomes materially riskier when it can act. A generated paragraph can be reviewed. A tool call may send a message, expose a record or change production data.
Prompt injection is part of the problem, but a secure design does not depend on detecting every malicious instruction. It limits what any instruction can cause.
Separate instructions from untrusted data
Documents, web pages, emails and retrieved passages are data even when they contain imperative language. Keep that trust boundary explicit in the architecture and prompts.
Prefer structured extraction between untrusted content and a decision. For example, extract fields into a narrow schema, validate them, and let a separate step decide whether a tool may be used.
Minimise capabilities
Give the workflow only the tools, accounts and records needed for the current task. Read-only access should not silently become write access. A customer-facing task should not inherit a broad internal service credential.
Short-lived, user-scoped credentials reduce the damage from both mistakes and attacks. Allowlists for domains, repositories, endpoints and record types provide another useful boundary.
Validate before action
Tool arguments should pass ordinary software checks. Validate types, ranges, identifiers and business rules. Reconfirm the current user’s authority at the time of the action rather than trusting text generated earlier in the workflow.
For consequential actions, show a person what will happen and require an explicit approval. The confirmation should describe the real effect, not only the tool name.
Keep secrets out of the model context
Do not place credentials in system prompts, retrieved documents or model-visible logs. Tools can use credentials behind a controlled interface without exposing them to the model.
Apply the same discipline to personal and confidential data. Retrieve only the records required for the current user and purpose, and make access decisions outside the model.
Make incidents diagnosable
Record the inputs, policy decisions, selected tool, validated arguments, approval and outcome at a proportionate level. Logs should help answer what happened without becoming a second store of sensitive prompts.
Security here is layered: narrow access, deterministic checks, human control where impact demands it, and enough evidence to investigate. Model behaviour can improve, but the system should remain safe when it is confused.