AI Agent Security Checklist: Permissions, Prompt Injection, Approvals, and Auditability

AI Agent Security Checklist: Permissions, Prompt Injection, Approvals, and Auditability

AI agents can browse websites, call APIs, create files, run code, access connected accounts, and change external systems. Those capabilities create business value, but they also expand the security boundary. A chatbot that produces a poor answer is frustrating. An agent with excessive access can send the wrong message, expose sensitive data, overwrite a record, or spend money.

Secure deployment does not mean eliminating autonomy. It means designing authority deliberately.

This checklist explains the controls businesses should apply to any production agent and how Actus Agent uses tool restrictions, approval queues, sandboxed execution, budget caps, and run traces to support governed work.

1. Define the agent’s job precisely

Security begins with scope. “Help with operations” is not an enforceable role. “Collect public competitor pricing and generate a weekly internal report” is.

Document:

• The approved objective
• Permitted data sources
• Allowed tools
• Prohibited actions
• Required output
• Approval points
• Completion evidence
• Escalation conditions
• Data retention expectations
• The human owner

A narrow job reduces ambiguity and makes unusual behavior easier to detect.

2. Apply least privilege

An agent should receive only the access required for its task. A research agent does not need billing administration. A content agent does not need database deletion rights. A reporting agent may need read access without write access.

Least privilege should exist at several levels:

• Account permissions
• Connector scopes
• Tool allowlists
• Domain restrictions
• File-system access
• Database policies
• Credential selection
• Runtime network access
• Action-specific approvals

The NIST Cybersecurity Framework 2.0 and NIST AI Risk Management Framework both emphasize governance and risk-informed controls. For agents, permission design is one of the clearest bridges between those frameworks and daily operation.

3. Treat retrieved content as untrusted

A browser agent may encounter malicious instructions embedded in webpages, documents, emails, or tool results. The content might tell the agent to ignore its objective, reveal a credential, visit another site, or execute a destructive action.

This is prompt injection. Unlike ordinary malicious input, it targets the model’s decision process.

The OWASP Top 10 for LLM Applications places prompt injection among the major risks for language-model systems. The UK National Cyber Security Centre has explained why prompt injection remains structurally different from SQL injection: natural-language systems cannot always cleanly separate instructions from data.

Defenses should be layered:

• Mark external content as untrusted
• Keep system rules outside retrieved text
• Prevent webpages from expanding tool permissions
• Require approval for consequential actions
• Restrict accessible domains
• Remove secrets from unnecessary context
• Scan tool outputs for suspicious instructions
• Stop when the page attempts to redefine the task
• Verify destinations before sending data

No single classifier is sufficient.

4. Separate reading from writing

Read access is generally lower risk than write access. Design the workflow so research and preparation can happen automatically while external changes require stronger authorization.

A practical three-tier model is:

Read: Search, browse, retrieve, and analyze approved information.

Prepare: Generate drafts, files, proposed updates, or queued actions.

Commit: Send, publish, purchase, delete, change permissions, or modify production records.

Agents can often automate the first two tiers safely. The third deserves explicit approval until reliability is demonstrated and consequences are understood.

5. Use approval gates

Approval should occur at the decision boundary, not at the beginning of an entire run.

A person might authorize the agent to research freely but still review the final recipients and content before email is sent. The agent can build a website while waiting for approval before production deployment. It can prepare invoice data without initiating a payment.

Actus provides an approval queue for sensitive tool actions. The run can pause while retaining context, then continue after the user approves or rejects the step.

Approval requests should state:

• The exact action
• The target
• The data being shared
• The expected effect
• Whether the action is reversible
• The cost
• The evidence used to prepare it

“Allow?” is not enough.

6. Protect credentials

Do not place raw passwords, API keys, or session tokens inside prompts. Credentials should be stored in a dedicated secret system, encrypted at rest, scoped narrowly, and injected only into the tool that needs them.

Rotate high-value keys, revoke unused connections, and prefer short-lived tokens where supported. Log credential use without logging the credential itself.

Actus states in its privacy policy that connected-account tokens and user API keys are encrypted at rest. Users should still configure external accounts according to least privilege.

7. Isolate execution

Code execution and computer use should happen in isolated environments. A generated script may contain mistakes, unsafe dependencies, or unexpected file operations.

Isolation should include:

• Per-run or per-user sandboxes
• Restricted host access
• Resource limits
• Controlled network access
• Temporary working directories
• File-size limits
• Process timeouts
• Dependency controls
• Cleanup after completion

Actus uses a sandboxed shell per run, allowing real code execution without equating tool access with unrestricted server access.

8. Enforce budgets and iteration ceilings

Cost is a security boundary. A compromised or confused agent can create denial-of-wallet behavior through repeated model calls, searches, or tool operations.

Set:

• A per-run spending limit
• An account-wide budget
• An iteration maximum
• Tool-specific quotas
• Concurrency limits
• Rate limits
• Alerts near thresholds
• Hard rejection after the cap

Actus checks the run’s budget on every iteration and performs a second account-wide check to catch simultaneous runs. Its pricing page describes how credits and caps apply.

9. Verify every consequential result

An agent should not infer success from an attempted action. Define evidence.

For record updates, read the record back. For a document, verify the file exists and opens. For a deployment, check the returned status and URL. For a message, require a provider confirmation. For a scheduled job, store a completed state only after the artifact is delivered.

Actus uses a claim-verification pass before presenting the final response. Claims such as “sent,” “saved,” or “deployed” must correspond to successful tool results.

10. Preserve an audit trail

An audit trail should show:

• Who initiated the task
• Which agent configuration was used
• Which tools were called
• What inputs and targets were involved
• Which approvals were requested
• Who approved them
• What artifacts were created
• Which errors and retries occurred
• The final verified state
• Relevant timestamps and correlation identifiers

Logs should avoid exposing secrets while retaining enough detail for investigation.

Auditability is essential when several team members and multiple agents share a workspace. It turns a mysterious outcome into a reviewable sequence.

11. Defend against duplicate actions

Retries create a specific risk: the first action may succeed even if its response is lost. Sending again may duplicate an email, charge, post, or database record.

Use idempotency keys, unique constraints, collision checks, and read-after-write verification. On an ambiguous response, reconcile state before retrying.

The AWS Builders’ Library guidance on retries explains why retries need backoff and idempotent design.

12. Control outbound data

Before an agent sends information to an external service, determine:

• What data is leaving
• Why the service needs it
• Whether personal or regulated information is included
• Which provider retains it
• Whether training uses are permitted
• How deletion works
• Whether the destination is correct

Redact or minimize data whenever possible. Do not give a model an entire customer file when a few fields are sufficient.

13. Design safe stop conditions

A good agent knows when not to continue.

Stop or escalate when:

• Identity is ambiguous
• Authentication fails
• A source conflicts with another authoritative source
• The requested action is outside scope
• A page presents suspicious instructions
• The destination changes unexpectedly
• A budget threshold is reached
• Required evidence is unavailable
• The action is irreversible and approval is missing
• A retry could duplicate an outcome

Honest incompletion is safer than confident guessing.

14. Test before granting autonomy

Begin in shadow mode. Let the agent perform the work without changing external state, then compare its proposed actions with the human process.

Next, allow preparation while requiring approval for execution. Review failure patterns. Only automate low-risk steps that repeatedly meet the acceptance criteria.

Use adversarial tests:

• Malicious instructions inside a webpage
• Conflicting customer records
• Expired login sessions
• Duplicate entities
• Unexpected pop-ups
• Missing required fields
• Tool timeouts
• Model-provider failure
• Oversized files
• Incorrect destinations

Security testing should reflect the real tools and data the agent will encounter.

15. Review the system continuously

Agent behavior changes when models, tools, websites, permissions, and workflows change. Reassess after:

• Adding a connector
• Expanding an agent’s role
• Changing models
• Modifying approval rules
• Updating a browser workflow
• A security incident
• A near miss
• A material increase in volume
• A new regulatory obligation

The MITRE ATLAS knowledge base catalogs adversarial tactics and techniques for AI systems and can help teams structure threat modeling.

A minimum production checklist

Before enabling an agent:

• [ ] One clear business objective
• [ ] Named human owner
• [ ] Tool allowlist
• [ ] Least-privilege credentials
• [ ] Isolated execution
• [ ] External content treated as untrusted
• [ ] Approval gates for consequential actions
• [ ] Per-run and account-wide budgets
• [ ] Iteration and concurrency limits
• [ ] Duplicate protection
• [ ] Task-specific verification
• [ ] Action and approval logs
• [ ] Data retention policy
• [ ] Incident and revocation process
• [ ] Shadow-mode testing completed

How Actus supports governed autonomy

Actus combines real execution with controls: sandboxed runs, approved tools, budget enforcement, iteration ceilings, sensitive-action approvals, traces, retries, model fallbacks, and final claim verification.

The purpose is not to promise risk-free autonomy. No complex system can make that promise. The purpose is to make authority visible, bounded, and reviewable.

Final perspective

The question is not whether an AI agent can perform an action. The question is whether it should, under which identity, with what access, after which checks, and with what evidence.

Explore Actus Agent by starting with a narrow workflow and this checklist. Expand autonomy only when permissions, verification, and observed performance justify it.