AI agent security is a system-design problem. An agent can receive untrusted instructions, call tools, access sensitive data, retain memory, and take actions. Securing only the model endpoint leaves the most important attack paths exposed.
Business and technical owners should review the following controls before deployment.
Identity and least privilege
Give the agent its own identity. Do not reuse a broad employee credential or shared administrator account. Grant only the permissions needed for the approved workflow, limit the records and environments it can reach, and use short-lived credentials where possible.
Tool boundaries
Maintain an explicit allowlist of tools and actions. Validate every tool input against a schema and business rule. Separate read, draft, and execute permissions. High-impact actions should require an additional control such as human approval, transaction limits, or a second system check.
Untrusted content
Treat webpages, emails, documents, retrieved records, and tool responses as untrusted data. They may contain instructions intended to redirect the agent. Keep system instructions separate, label data clearly, minimize unnecessary context, and test indirect prompt-injection scenarios.
Data protection
Map what information enters prompts, memory, logs, connected tools, and outputs. Apply classification rules, redaction, retention limits, and access controls. Do not assume a secure model contract makes every connector or custom log secure.
Memory controls
Define what the agent may remember, who can read or change that memory, and when it expires. Validate information before persistence. Provide a way to correct or delete poisoned, outdated, or inappropriate memory.
Human approval
Place approvals before consequential, external, privileged, expensive, or difficult-to-reverse actions. Show the reviewer what the agent plans to do, the relevant evidence, and the exact target. Avoid approval fatigue by keeping low-risk steps separate.
Testing and change control
Test expected tasks, malformed input, conflicting instructions, malicious documents, unavailable tools, permission errors, excessive loops, data leakage, and recovery. Re-test when the model, prompt, tool, data source, permission, or memory architecture changes.
Observability and response
Log agent versions, tool calls, approvals, failures, overrides, and security events with appropriate data minimization. Set thresholds for abnormal volume, unusual tool sequences, repeated denials, and unexpected data access. Name an incident owner and maintain a tested kill switch.
Launch decision
Before production, confirm that the business owner accepts the residual risk, the technical owner can roll back, the operational owner can investigate behavior, and users understand the agent's limits. Start with narrow scope and increase authority only when evidence supports it.
The safest agent is not necessarily the least capable. It is the one whose capability is matched by explicit authority, limited access, observable behavior, and a reliable recovery path.