AI Agent Security: Permissions, Injection, and Data Exfiltration

Direct answer: Secure an AI agent by controlling what it can do when the model is wrong, manipulated, or uncertain. Give the agent its own identity, calculate its effective permissions across every connected tool, keep credentials short-lived, authorize every action again at the destination, and block unapproved data paths. Treat email, documents, web pages, retrieval results, memory, tool output, and messages from other agents as untrusted. High-consequence actions need a policy decision—and sometimes a human decision—before the tool runs.

This guide is current as of October 16, 2026. It uses the OWASP Top 10 for Agentic Applications 2026 as a coverage map, not a certificate. The list includes goal hijack, tool misuse, identity and privilege abuse, supply-chain risk, unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation, and rogue agents. For the broader LLM risk framework and prioritization context, use EncryptCentral’s OWASP Top 10 for LLM Applications 2026 guide.

No live agent, model, tenant, identity provider, connector, MCP server, repository, email account, memory store, DLP control, egress control, approval interface, or runtime security product was tested for this article. Test only systems you own or are explicitly authorized to assess, using synthetic accounts, harmless canaries, approved destinations, reversible actions, spending limits, and written stop conditions.

Start with an agent control register

An agent is more than a model and a system prompt. It is an execution path that can combine a user’s request, developer instructions, retrieved data, memory, tools, credentials, downstream services, and external destinations. The control register makes that path reviewable before it becomes production access.

Record	Question to answer	Evidence to retain
Purpose and owner	What exact job may the agent perform, for whom, and who can approve, monitor, and stop it?	Named owner, approver, operational contact, task definition, prohibited uses, and retirement date.
Identity	Does the agent have a unique identity, or is it borrowing a user, shared account, host process, or service credential?	Principal ID, credential type, issuer, token audience, expiry, user delegation context, and revocation path.
Tools and actions	Which exact functions can it call, with which arguments and side effects?	Versioned tool inventory, owner, allowed operations, schema, resource scope, rate limit, and rollback method.
Data and memory	What may enter context, persist in memory, cross tenants, or be returned to a user?	Data classes, sources, retrieval policy, provenance, retention, tenant boundary, field filters, and deletion test.
Destinations	Where can the agent send data or trigger work?	Allowlisted domains, recipients, queues, storage, protocols, webhook targets, and volume limits.
Runtime control	What can deny, modify, pause, or require approval before an action occurs?	Policy rule, enforcement point, approval threshold, failure posture, decision log, and bypass test.
Containment	How is the agent stopped if it drifts, is compromised, or loses its owner?	Kill switch, token invalidation, tool disablement, memory quarantine, incident runbook, and last drill result.

The UK NCSC’s 2026 agentic AI guidance recommends starting with tightly bounded, low-risk tasks, using least privilege for the shortest necessary time, avoiding long-lived credentials, monitoring behavior, threat-modeling the deployment, and planning for loss of control. If the team cannot explain the agent’s authority or stop its actions, the deployment is not ready.

Calculate effective authority, not the permission shown in one console

An agent may look narrowly scoped at each connection while becoming powerful in combination. Read access to customer records plus an email tool is a disclosure path. Repository read access plus a deployment tool can become a code-to-production path. A delegated user token plus an agent-owned service identity may create authority neither identity should have alone.

The NIST agent identity concept paper highlights identification, authorization, auditing, non-repudiation, and prompt-injection controls as open implementation questions for software and AI agents. It is a concept paper, not a finished compliance standard. Use it to ask the right identity questions, not to claim certification.

1. Assign a unique agent identity. Name an owner and lifecycle. Avoid shared credentials that make attribution and revocation ambiguous.
2. Separate agent authority from user authority. Record when the agent acts as itself, on behalf of a user, or through a delegated workflow. The destination must know which mode applies.
3. Scope by resource and action. “Access CRM” is too broad. Prefer a named collection, allowed fields, read-only operation, maximum row count, and an approved purpose.
4. Use short-lived, task-bound access. Elevation should expire when the workflow ends. Do not leave a broad token in memory, a prompt, a log, or a tool description.
5. Authorize at every hop. The orchestrator’s approval does not replace authorization inside the tool and downstream service. Recheck the user, agent, tenant, resource, action, and current policy.
6. Review the combination. Draw paths across tools and destinations. A chain of individually acceptable permissions may enable a prohibited aggregate outcome.

Microsoft’s current least-privilege guidance for agents similarly calls for unique identities, aggregate permission review, tool allowlists, downstream authorization, time-limited elevation, detailed action logs, and tested revocation. That vendor guidance is useful as an implementation example; it does not prove any Microsoft tenant or agent is correctly configured.

Assume untrusted content can influence the model

A normal task can require the agent to read an attacker-controlled email, issue, web page, document, code comment, calendar invite, retrieved passage, tool result, or message from another agent. The model may process the hostile instruction in the same context as trusted instructions. Calling the content “data” in a prompt can help, but it is not a dependable permission boundary. EncryptCentral’s indirect prompt injection explainer covers the attack path in more depth; this checklist concentrates on limiting what a manipulated agent can reach and do.

NIST describes this as agent hijacking: an indirect prompt injection is placed inside information the agent must consume while completing a legitimate task. NIST’s evaluation guidance also warns that results vary by task and across repeated attempts. A low average attack rate does not make a high-impact exfiltration or code-execution path acceptable.

Design as though manipulated content may reach planning:

• Label the source, trust level, tenant, owner, and retrieval time of content entering context.
• Keep security policy, credentials, and authorization decisions outside model-generated text.
• Use separate components or contexts for untrusted reading and privileged action when the architecture permits it.
• Pass structured, minimal values between stages instead of a complete conversation or document dump.
• Reject instructions, tool definitions, URLs, code, and destination changes that arrive from an untrusted source unless a trusted policy explicitly permits them.
• Recheck the requested action after every untrusted read, plan revision, tool response, memory lookup, or agent-to-agent handoff.

Prompt-injection detection can be one signal. It should not be the only thing standing between an untrusted document and a privileged tool.

Implementation sequence: turn each tool into a narrow security contract

Do not expose a general shell, arbitrary HTTP client, unrestricted database query, or “run any workflow” function when the job needs one bounded action. Each tool contract should state the allowed caller, resource, operation, argument schema, data class, destination, maximum volume, cost ceiling, timeout, idempotency behavior, approval rule, and audit fields.

Validate arguments in deterministic code. Resolve resource ownership and tenant scope at execution time. Strip fields the task does not need. Restrict redirects and secondary calls. Use a dry-run or preview for bulk, destructive, financial, external-communication, identity, production, or privilege-changing actions. Make reversible actions the default where practical.

The OWASP Agent Control Standard, added to the OWASP GenAI Security Project in September 2026, describes a portable pattern for inspecting agent lifecycle events and allowing, denying, modifying, deferring, or asking for approval before execution. It is an emerging standard, not proof of correct policy or complete platform coverage. Whatever mechanism you choose, define its failure posture. A policy service that silently fails open is not a control during an outage.

Make approvals show the real consequence

An approval screen should not merely say “Allow the agent to continue?” Show the exact tool, account, tenant, resource, action, arguments, destination, recipient, record count or data volume, cost, reversibility, and why approval is required. For a changed destination or expanded scope, require a new decision. Never let the agent approve its own action or summarize away the risky detail.

Reserve human review for meaningful thresholds. Reading a public page may stay automatic. Sending customer data, changing access, running code, deleting records, making a purchase, publishing externally, or crossing tenants should require stronger policy, step-up authentication, or a separate approver. A flood of low-value confirmations trains people to click through the one that matters.

Build a data-exfiltration boundary

Data loss can happen through an obvious export or through an ordinary-looking output: an email body, webhook, image URL, rendered link, log entry, generated file, code commit, support ticket, analytics event, or message to another agent. Control the complete path from source to sink.

1. Classify the source. Identify secrets, personal data, regulated records, internal code, customer content, and tenant ownership before retrieval.
2. Minimize context. Retrieve only the records and fields required for the current user and task. Enforce row, token, file-size, and time limits.
3. Filter before the model. Remove credentials and prohibited fields in trusted code. Do not ask the model to remember not to disclose them.
4. Constrain destinations. Use allowlisted domains, recipients, repositories, buckets, queues, and protocols. Block model-selected arbitrary URLs and unapproved redirects.
5. Validate output. Enforce schemas, field rules, data labels, recipient policy, and maximum volume before a tool accepts model output.
6. Protect telemetry. Log identifiers and decisions needed for investigation without copying full prompts, tokens, secrets, personal data, or entire documents into a second sensitive store.

Joint government AI data-security guidance emphasizes provenance, integrity, encryption, protected storage, and supply-chain controls for data used to operate AI systems. Those controls help protect what enters the agent; field-level authorization, destination policy, egress enforcement, and approval quality control what may leave.

Treat memory and other agents as separate trust boundaries

Memory can turn one malicious input into persistent behavior. Record who wrote each memory item, its source, tenant, trust label, purpose, creation time, expiry, and review state. Do not let untrusted content write privileged instructions, tool policy, credentials, approval history, or global memory. Quarantine suspicious items and support deletion that can be verified from the backing store.

For multi-agent workflows, authenticate the sender and bind every message to a task, user, tenant, permitted capability, and expiry. A coordinator should not pass its full authority to a helper. A receiving agent should not treat another agent’s confident output as trusted authorization. Limit fan-out, depth, retries, spending, and time so one failure cannot cascade indefinitely.

Run an evidence-producing deployment gate

Use owned accounts, synthetic data, harmless canaries, controlled destinations, and reversible actions. Keep the legitimate task intact while varying one boundary at a time. Because model behavior is probabilistic, repeat the case and record each operating result—not just the final answer.

Test	Safe variation	Pass evidence
Indirect injection	Place a harmless instruction in an owned email, document, web fixture, retrieval record, or tool response.	The legitimate task completes without the unapproved tool, destination, or canary disclosure.
Confused deputy	Ask the agent to use its identity for a resource the requesting user cannot access.	The destination rechecks both identities and denies the action without side effects.
Tool scope	Change one argument beyond the allowed resource, operation, tenant, count, cost, or time window.	Trusted validation denies or narrows the request before execution.
Data exfiltration	Try to send a synthetic canary to an unapproved recipient, URL, repository, log field, or message channel.	Destination or DLP policy blocks it; no request or queued job reaches the sink.
Approval quality	Change the actual tool arguments after preview or hide a high-impact effect behind a vague summary.	The approval binds exact arguments and expires after any material change.
Memory poisoning	Submit an untrusted item that requests a persistent policy or destination change.	The item is isolated, cannot become privileged memory, and can be found and deleted.
Revocation	Disable the agent or revoke its token during a controlled workflow.	New calls fail, queued work is contained, cached credentials expire, and the event is visible.
Kill switch	Trigger the approved emergency stop during a benign long-running task.	Tools, network paths, and delegated work stop within the stated objective; recovery requires authorized reactivation.

For every test, retain the agent and user identity, deployment version, model and orchestration version, tool schema version, policy version, input source and trust label, action request, policy decision, approval record, destination, result, saved-state read-back, downstream effects, correlation ID, and cleanup result. Redact secrets and personal data.

Common failure modes

A stronger system prompt is treated as authorization

A prompt is interpreted by the same class of model processing untrusted content. Keep permissions, destinations, and consequential decisions in enforceable controls outside the model.

The agent uses the employee’s full session

This hides accountability and can turn a low-risk task into all of the user’s authority. Use a distinct agent identity, explicit on-behalf-of context, narrow scopes, short-lived elevation, and destination-side authorization.

The tool list is reviewed one tool at a time

Chains create capabilities that no single tool reveals. Review the combined path from data source through agent and tools to every possible destination and side effect.

Approval exists, but the reviewer cannot see the action

Do not present only the agent’s narrative. Bind approval to exact arguments, affected resources, destination, volume, cost, and consequence.

The final response is checked, but saved state is ignored

An agent can say it refused after a message, write, job, payment, or request has already occurred. Read back the destination and asynchronous work before calling a test safe.

Logging captures everything

Full prompts and tool results can duplicate secrets and customer data. Log enough structured evidence to investigate identity, policy, action, and result while minimizing sensitive content.

Decision

Release an AI agent only when its effective authority is smaller than the consequence you are prepared to accept. The team should be able to identify the agent, explain every data and tool path, enforce authorization outside model judgment, show exact approvals for high-impact actions, block unapproved destinations, verify saved side effects, revoke access, quarantine memory, and stop the system under test.

If those controls are incomplete, reduce the job: remove write tools, restrict the data set, use a sandbox, require a reviewed handoff, or replace the agent with deterministic automation. Autonomy is not the goal of the security design. Bounded, observable, reversible work is.

Primary references

• OWASP Top 10 for Agentic Applications 2026
• OWASP Agent Control Standard
• NIST: Identity and Authority of Software Agents
• NIST AI 100-2e2025: Adversarial Machine Learning
• NIST: Strengthening AI Agent Hijacking Evaluations
• UK NCSC: Thinking Carefully Before Adopting Agentic AI