How to Secure AI Agents: Tool Permissions, Human Approval, and Audit Logs

Start with authority, not intelligence

The security question for an AI agent is not only how capable the model is. It is what the system allows the model to do.

A model that drafts text in an isolated window has a different risk profile from an agent that can browse untrusted pages, read private files, execute code, update a database, send messages, deploy software, or create additional agents. Capability becomes operational risk through identity, tools, permissions, data, and action environments.

The UIUC one-day vulnerability study ↗ and multi-agent zero-day study ↗ are offensive capability evaluations, but they expose a defensive design truth: tool access, useful documents, planning, specialization, and repeated attempts can materially change what an agent system accomplishes.

1. Give the agent its own identity

Do not let an agent silently inherit a human administrator session. Use a distinct service identity with a clear owner, purpose, expiration policy, and revocation path.

Separate identities improve the audit trail. They also make it possible to limit access without blocking the human operator. In a multi-agent system, use separate identities or enforceable scopes for specialists instead of treating the entire team as one unlimited principal.

NIST's 2026 work on software and AI agent identity and authorization ↗ frames this as a dedicated security problem because agents may take actions with limited supervision across multiple data sets, tools, and applications.

2. Default tools to read-only

Start with the least powerful version of every tool. Reading an issue is different from closing it. Drafting a message is different from sending it. Previewing a database change is different from committing it. Producing a patch is different from deploying it.

Where a write action is necessary, narrow it:

• Allow a specific API operation instead of unrestricted shell access
• Limit the repository, branch, workspace, tenant, or account
• Require structured arguments with server-side validation
• Put rate, time, cost, and affected-resource limits around the action
• Keep production and test credentials separate

The NIST agent tool-use taxonomy ↗ distinguishes read-only, constrained-write, and write-capable agents, and also distinguishes trusted from untrusted environments. That is a useful starting map.

3. Put human approval at consequential boundaries

Human review should not mean approving every harmless read. That creates fatigue and teaches people to click through prompts. Put approval where the action becomes hard to reverse or affects another person.

Typical approval boundaries include:

• Deploying to production
• Deleting or overwriting data
• Sending an external email or public message
• Moving money or changing payment details
• Creating, disabling, or changing an account
• Rotating credentials or modifying access policy
• Sharing customer, employee, health, financial, or legal information
• Launching a security test outside an isolated authorized environment

The approval screen should show the exact action, target, scope, evidence, expected effect, and rollback path. “Approve agent plan” is too vague.

4. Treat retrieved content as untrusted data

An agent may be instructed by its operator to read a webpage, ticket, email, document, image, repository, or tool response. The content can contain text designed to redirect the agent, reveal data, or call a tool.

The system should distinguish high-trust operator policy from lower-trust retrieved content. External content should not gain authority merely because it appears inside the model's context window.

Practical controls include:

• Label source and trust level
• Keep system policy separate from retrieved text
• Do not expose secrets to agents that inspect arbitrary content
• Validate URLs, commands, queries, and tool arguments outside the model
• Require approval when untrusted input contributes to a high-impact action
• Test indirect prompt-injection cases before production rollout

5. Validate model output before execution

Generated text is not a security decision. Treat every command, query, URL, file path, recipient, amount, and permission request as untrusted until validated by deterministic code and policy.

Use allowlists when the valid action space is small. Resolve paths and targets before a destructive operation. Prevent private-network and metadata-service requests in URL tools. Reject unsupported protocols. Require exact schemas, length limits, and business-rule checks.

Validation should happen at the tool boundary so it cannot be bypassed by a persuasive model explanation.

6. Constrain planners, managers, and specialists separately

Multi-agent systems create new delegation paths. A planner may create tasks, a manager may assign specialists, and a specialist may receive tools or documents. Every handoff needs a policy decision.

Ask:

• Can the planner create unlimited subagents?
• Can a manager grant a specialist new tools?
• Can a specialist act directly, or only return evidence?
• Does the manager verify evidence before execution?
• Can one agent write instructions into shared memory for another?
• Can data cross customers, tenants, or sensitivity levels?
• Can reviewers attribute an action to the requesting and executing agents?

Task specialization can improve performance, as the HPTSA ablations suggested, but it should narrow authority rather than multiply it.

7. Scope shared memory and retrieval

Memory can preserve useful context across attempts. It can also preserve malicious instructions, stale security information, secrets, or data from the wrong tenant.

Define what enters memory, who can read it, who can write it, how long it persists, and how it is deleted. Separate short-lived task state from durable knowledge. Attach source, timestamp, and trust information to security advisories and retrieved documents.

For CVE decisions, keep the official vendor advisory, CISA KEV status, internal asset evidence, and assumptions separate. Use the CVE Exposure & Response Planner to organize that context without submitting it to CheckLink.

8. Log actions, not unnecessary secrets

A useful audit record should capture:

• The agent and human identities involved
• The tool and operation requested
• The target and scope
• The policy decision
• The approval, denial, or modification
• The external effect and result
• Failures, retries, and limit events

Avoid logging raw secrets, private keys, full customer records, or unnecessary message content. Observability and privacy are both security controls.

9. Add budgets, rate limits, and stop conditions

Agents can repeat an action at machine speed. Limit the number of attempts, elapsed time, token or monetary budget, requests per target, parallel workers, and resources affected.

Define stop conditions for repeated failure, unexpected authorization errors, policy disagreement, environment changes, and unverified external instructions. A planner should not interpret a limit as a challenge to find another path around it.

10. Keep pause, revoke, and recovery outside the agent

An operator needs a way to stop the workflow that does not depend on asking the same agent to stop itself. The control plane should be able to disable tools, revoke credentials, terminate active jobs, preserve logs, and isolate affected resources.

Prepare an incident playbook for prompt injection, unexpected write actions, exposed credentials, incorrect external messages, cross-tenant data, and compromised retrieval sources. Test the playbook in a sandbox.

11. Evaluate in an isolated environment

The cited UIUC work reproduced vulnerabilities in sandboxes and withheld offensive prompts and code. Production agent teams should use the same separation for defensive evaluation.

Use synthetic accounts, reserved domains, test repositories, fake payment data, inert documents, and non-production credentials. Include normal workflows, ambiguous cases, malicious instructions inside retrieved content, failed tools, partial outages, and attempts to expand permissions.

Do not treat a successful demo as evidence of safe behavior under adversarial input.

12. Build a patch-response path before disclosure

The one-day study found that a vulnerability description materially increased agent performance. That makes vulnerability-response readiness part of AI-era defense even for organizations that do not deploy AI agents themselves.

Maintain a current asset inventory, subscribe to official advisories, track affected versions, record CISA KEV status, assign owners, predefine emergency change paths, test rollback, and verify the installed result. Do not let CVSS alone decide priority.

For a higher-impact case, the Rapid CVE Readiness Review provides a manual, non-intrusive decision-support path.

A practical pre-deployment gate

Before a production agent receives tools, require evidence for these questions:

1. Which identity will act?
2. What can it read, write, send, execute, or delete?
3. Which inputs are untrusted?
4. Which generated arguments are validated outside the model?
5. Which actions require a human decision?
6. What can planners and subagents delegate?
7. How is shared memory scoped and deleted?
8. What is logged, and which sensitive data is intentionally excluded?
9. Which budgets and stop conditions apply?
10. How can an operator pause, revoke, investigate, and recover?

The free AI Agent Security Checklist scores these controls transparently and creates a copyable action plan. It runs entirely in the browser and does not inspect the agent.

What a manual review adds

A checklist can expose missing questions, but it cannot verify an architecture. The AI Agent Security Review maps identities, authority, tools, trust boundaries, approvals, memory, logging, and recovery evidence for a defined system.

It is not a security certification, an exploit-development service, or permission to test third-party systems. The purpose is to make consequential agent behavior reviewable before it becomes a production incident.

Bottom line

Secure AI agents by controlling the path from model output to real-world action. Identity, least privilege, untrusted-input boundaries, deterministic validation, explicit approval, scoped delegation, privacy-aware logs, limits, and independent recovery matter more than a promise that the model will always behave correctly.

Read the measured results, limitations, and newer research context in the AI Cybersecurity Research Hub. Then turn the findings into evidence your team can review.