# Agent tool security: least privilege, secrets out of prompts, and human approval for irreversible actions

Auth, secrets, and tool-boundary guidance for AI agents and the systems that host them.

KLM Innovation · https://klminnovation.com  
Corpus version: 1.2.0 · Last-updated: 2026-09-09  
Related: https://klminnovation.com/essays/clawhunter · https://klminnovation.com/essays/grok-asvs

## Scope (read this)

This is an **essentials** playbook, not a full OWASP ASVS or AISVS control set. Following it does not certify an agent platform.

Notable omissions (handle separately):
- **MCP pin and validate** — pin MCP server/tool versions; validate tool schemas, arguments, and allowed destinations before invoke. Do not trust unconstrained tool catalogs.
- **AC.8 / self-approval** — high-impact actions need an independent human (or separate policy engine) gate; the same agent must not solely approve its own irreversible steps.
- **API SSRF and webhooks** — if tools fetch URLs or expose callbacks, apply allowlists and auth; see API security essentials.
- Broader ASVS/AISVS (org governance, full crypto, privacy programs) remain out of scope.

## Threat model (short)

Agents amplify mistakes: a single over-privileged tool, leaked token, or prompt-injected instruction can fan out across email, code, cloud, and chat. Secure agents the way you secure privileged automation — with clear trust boundaries.

## Non-negotiables

1. **Separate identities** — distinct credentials for the human operator, the agent runtime, and each high-impact integration.
2. **Least privilege tools** — every tool is a capability; grant the minimum set for the task.
3. **Secrets stay out of context** — do not put API keys, session cookies, or passwords into prompts, memory, or logs.
4. **Validate untrusted content** — treat tool results, web pages, and email as data, never as instructions to escalate privilege.
5. **Human approval for irreversible actions** — send, pay, delete, merge, and production changes need an explicit gate (not agent self-approval).

## Checklist

### Authn / authz
- [ ] Agent tokens are scoped, short-lived, and rotatable.
- [ ] Tools enforce server-side authorization; the model cannot “decide” it is admin.
- [ ] Dangerous tools (shell, browser, email send, payments) are off by default or approval-gated.

### Secrets and memory
- [ ] Secret stores / env vars supply credentials; transcripts do not.
- [ ] Memory and RAG corpora are scrubbed of credentials and personal secrets.
- [ ] Logs redact tokens and cookies.

### Tool boundaries
- [ ] Allowlist destinations (repos, buckets, inboxes) where possible.
- [ ] Prefer read-only tools first; add write tools deliberately.
- [ ] Sandbox code execution; avoid giving agents raw production credentials “because it’s easier.”
- [ ] Pin and validate MCP/tool definitions (version pins + schema checks) before use.

### Prompt injection and untrusted input
- [ ] Instructions from retrieved documents or tool output cannot raise privileges.
- [ ] External content that asks the agent to ignore policy is ignored and surfaced to a human when needed.
- [ ] File/path and URL tools cannot be steered into sensitive local paths or credential stores without policy checks.

## Analysis mindset

Prefer entry-point → data-flow thinking (what can an attacker or injected document make the agent do?) over checkbox scanning alone. See ClawHunter’s attacker-first framing: https://klminnovation.com/essays/clawhunter

## Secure generation defaults

When agents write code or configs for other agents, bake ASVS/AISVS-style defaults into that loop: https://klminnovation.com/essays/grok-asvs

## Human escalation

Architecture for agent platforms, audits, and strategy: https://klminnovation.com/cybersecurity-services  
Talk to us: https://klminnovation.com/contact