How can a company secure an AI agent that accesses business systems? Start by treating the agent as a software operator, not a clever chat window. Give it a dedicated identity, least-privilege access, narrow tools, validated inputs and outputs, approval gates for consequential actions, complete audit evidence and an incident plan that can stop and contain it. Prompts can guide behaviour, but identity, authorization and business rules must be enforced outside the model.

The security boundary changes when an AI system can read email, retrieve files, update a CRM, issue a refund or publish content. Untrusted text can now influence an action. A correct-looking response can target the wrong record. A stolen credential can turn a useful assistant into a high-speed operator. The checklist below is designed for business leaders, process owners and implementers to review one real agent before production access is granted.

First define the agent's security contract

Write a one-page contract stating the business purpose, accountable owner, permitted users, approved data classes, allowed tools, exact write actions, prohibited actions, monetary or volume limits, required approvals, normal operating hours, monitoring owner and shutdown method. If the team cannot describe those boundaries precisely, the agent is not ready for broad access.

Apply the contract per action. A lead-research agent may read public websites and create an internal summary without review, while still needing approval before it changes an opportunity or sends outreach. The five-level autonomy ladder helps match each action to its consequence and reversibility.

The 25-point AI agent security checklist

Identity

  1. 1. Give the agent its own non-human identity; never share a staff account.
  2. 2. Use short-lived credentials and managed secret storage.
  3. 3. Authenticate the requesting user before every sensitive operation.

Permissions

  1. 4. Allow only the tools, records, fields and actions required for the task.
  2. 5. Prefer read-only access until a write action is proven necessary.
  3. 6. Enforce permissions in the tool or API—not in prompt wording alone.
  4. 7. Set amount, volume, time and destination limits for permitted writes.

Data

  1. 8. Classify the data the agent may read, retain and disclose.
  2. 9. Exclude secrets and unnecessary personal data from model context and logs.
  3. 10. Treat retrieved documents, web pages, email and tool output as untrusted input.
  4. 11. Define retention, deletion and residency rules with the process owner.

Tools

  1. 12. Expose narrow operations with typed parameters instead of broad shell or database access.
  2. 13. Validate every tool argument against user authority and current business state.
  3. 14. Require idempotency keys or duplicate checks for consequential actions.
  4. 15. Keep irreversible or high-impact actions behind explicit human confirmation.

Output

  1. 16. Validate format, allowed values, destinations and business rules before execution.
  2. 17. Require evidence or source references for decisions that depend on retrieved facts.
  3. 18. Block instructions embedded in untrusted content from changing system authority.

Monitoring

  1. 19. Log the requester, source input, model and policy version, tool call, result and approval.
  2. 20. Alert on permission denials, unusual tool sequences, repeated retries and volume spikes.
  3. 21. Review exceptions and a risk-based sample of apparently successful work.
  4. 22. Re-test after model, prompt, tool, data or permission changes.

Incident response

  1. 23. Provide an owner-controlled way to pause jobs and revoke credentials.
  2. 24. Preserve a traceable record of actions without leaking protected content.
  3. 25. Document containment, rollback, notification and safe-restart steps.

Why prompt injection is an authorization problem

An agent may encounter a document, support ticket or website that contains instructions such as “ignore previous rules” or asks it to disclose hidden data. Filtering suspicious phrases helps, but it is not a complete control. The reliable design assumes external content may be hostile, keeps trusted instructions structurally separate, limits the tools available for the current task and validates every requested action against the authenticated user's permission and the workflow's policy.

OWASP's current prompt-injection guidance recommends least-privilege tool access, tool-specific parameter validation, human approval for destructive actions and comprehensive monitoring. Its Agentic AI threat material also recommends logging the originating input with agent actions and red-teaming before deployment. These are defence-in-depth controls: no single filter or “guardrail model” carries the whole security burden.

Build tools that are safe to call

Do not expose a general database query when the workflow needs “add an approved note to this opportunity.” Do not expose a general file system when it needs “read documents in this permitted folder.” A narrow tool should authenticate the caller, re-check the record, validate each parameter, enforce field and value constraints, return a preview for sensitive changes and produce an immutable operation ID.

Where integrations use the Model Context Protocol, the protocol can standardize discovery and invocation, but it does not replace authorization. The server must still enforce which person and agent may call which tool against which resource.

Test misuse, not only happy paths

A production evaluation set should include valid work, incomplete inputs, ambiguous identities, duplicate requests, stale records, hostile instructions inside retrieved content, encoded or multilingual attacks, permission failures, tool timeouts, malicious URLs, excessive retries and requests just above approval thresholds. Test whether the agent stops safely and whether the owner can reconstruct what happened.

NIST's AI RMF organizes this work around govern, map, measure and manage. Its core calls for testing before deployment and regularly in operation, documenting security and resilience, monitoring system behaviour, and maintaining appeal, override, incident response, recovery and change-management mechanisms. That turns security into a lifecycle rather than a one-time review.

What business leaders should ask before approval

  • Can the team show the exact permissions granted to the agent and the reason for each one?
  • Can an external document or user message expand those permissions? The answer must be no.
  • Which actions are previewed, approved, rate-limited, versioned or reversible?
  • What signal pauses the workflow automatically, and who receives the alert?
  • Can the team explain every production action from request through tool result?
  • When was the last adversarial test and recovery exercise?

Primary sources checked for this guide

Checked 26 August 2026. The controls above are grounded in current standards and security-project guidance.

Secure the authority, not only the prompt

Review one agent against all 25 controls

I help SME teams map identities, data, tools, approval gates, tests and incident ownership before an agent receives production access.

Review an AI agent