AI Agent Security

An AI agent with a tool is an AI agent with privileges. The moment a language model can execute code, query databases, send messages, or call external APIs, securing the prompt is no longer enough: you must decide, per user and per role, which actions the model may take on whose behalf — and prove it afterwards. That is AI agent security: authorization, enforcement, and observability for autonomous systems.

Why Agents Change the Threat Model

A chatbot's failure mode is a bad answer. An agent's failure mode is a bad action — executed with real credentials, against real systems, often without a human in the loop. The threat model extends accordingly: prompt injection becomes a privilege-escalation primitive, context poisoning becomes persistence, and confused-deputy chains combine legitimate tools into illegitimate workflows. Our MCP security guide covers this for the Model Context Protocol specifically.

Tool Permissions: Least Privilege in Practice

The single highest-impact control. Every tool grant should be justified by the task, and every grant you cannot justify is attack surface:

• Enumerate tools per agent — an agent that summarizes documents does not need email or database write access.
• Authorize per user, not per deployment — the agent acts on someone's behalf; its permissions should be a subset of that person's.
• Deny by default — a tool not explicitly granted fails closed, including for tool combinations nobody anticipated.

The full methodology is in Tool Permissions for AI Agents: Least Privilege in Practice.

Tool-Call Authorization with Capability Bitmasks

RESK enforces tool authorization with a 64-bit capability bitmask per role — bit 0 is "may call tools", and further bits cover code generation, database access, email, PII handling, and system configuration. Policies attach to masks, so security is enforced per role at every request, not negotiated per prompt. Enforcement is fail-closed: an unauthorized tool call returns an error before execution. The model is explained in Capability Bitmasks: Real RBAC for LLM Applications, and implemented in reskSecure and the ReskSafety firewall — editable live in the demo console.

Memory and Context Attacks on Agents

Agents accumulate context — conversation history, retrieved documents, tool results, and long-term memory. Each is an injection channel: memory poisoning plants instructions that persist across sessions; in-context injection hides payloads in indexed content ("dormant agents" activated by trigger tokens). Defenses: treat all retrieved and remembered content as untrusted input, scan before injection into context, and scope memory per user and per tenant. See prompt injection for the attack taxonomy.

Agent Observability and Audit

You cannot secure what you cannot see. Agent security requires logging every action with its parameters, probability, and result — not just the final answer. ReskPoints ships agent action logs to Datadog, Prometheus, OpenTelemetry, webhooks, or files, giving you the audit trail required for incident response and compliance. Combined with the firewall's per-request logs, you get the full chain: who asked, what policy allowed it, which tools ran, with what arguments, and what happened.

Pentest Your Agents

Agent deployments fail in ways unit tests never trigger: tool-call chains, poisoned retrieval, permission creep. Adversarial testing against your own deployment is the only way to find the gap between intended and actual privileges — see AI Red Teaming and our AI pentesting practice. To feed fake secrets to AI-powered scanners probing your infrastructure, deploy honeycrawlpot.

The RESK Agent Security Stack

Related Guides

• LLM Security — the foundation threat model
• MCP Security — securing the Model Context Protocol
• Tool Permissions for AI Agents
• Capability Bitmasks: Real RBAC for LLM Applications