Start with authority, not prompts
An agent can generate suggestions, but trusted software and accountable people must own identity, authorization, validation, side effects, and recovery. A system prompt can describe policy; it cannot enforce a filesystem boundary or approve a financial action.
Inventory every model, tool, resource, memory store, connector, credential, destination, and human decision. Draw trust boundaries and define which component can read, write, execute, communicate, or delegate.
Defend against direct and indirect prompt injection
Treat user input, web pages, files, tool output, and retrieved passages as untrusted data. Delimit evidence, preserve source identity, and prevent content from changing system authority. Test instructions hidden in documents, metadata, code comments, images, and tool responses.
Injection resistance is a system property. Combine narrow capabilities, schema validation, destination controls, data minimization, approvals, output validation, and monitoring rather than relying on one detection model.
Secure MCP connections and tools
Review server provenance, command, package, transport, identity, and enabled capabilities before connecting a client. Expose narrow task-specific schemas instead of arbitrary paths, URLs, commands, or query languages. Separate resources from actions and avoid write capabilities when read-only access is sufficient.
For remote servers, authenticate both parties, bind authorization to the user and client context, prevent token forwarding, validate redirects, and use least-privilege scopes. Record capability negotiation and deny unsupported methods.
Control side effects and incidents
Require a named human to approve the exact high-impact action, target, and content near execution time. Use idempotency keys, transaction boundaries, step budgets, cancellation, kill switches, and rollback. Trace decisions and tool calls without creating a sensitive transcript archive.
When exposure or unauthorized action is suspected, contain the path, revoke credentials, preserve evidence, assess affected data and actions, restore a known-good version, and add the failure to the regression suite.
Decision framework
| Area | Guidance |
|---|---|
| Threat boundary | Primary control |
| Retrieved hostile text | Treat as data; preserve authority outside the model |
| Overpowered tool | Narrow schema, identity, scope, destination, and rate |
| Dangerous side effect | Validation, exact approval, idempotency, and rollback |
| Compromised MCP server | Provenance, isolation, capability review, monitoring, and revocation |
Practical checklist
- List tools, data, identities, and destinations
- Remove unused capabilities
- Test direct and indirect injection
- Verify authorization before context assembly
- Require exact approval for high-impact writes
- Exercise kill switch and rollback
First-party sources
Source status last checked 2026-09-11. Links can change after publication.