How to Secure Enterprise AI Agents: Identity, Permissions and Prompt Injection

The agent is not the security boundary

An enterprise agent can read email, inspect documents, query databases and call business APIs. That combination is useful because it joins reasoning with action. It is also the reason an agent must be treated as an untrusted decision component inside a conventional security architecture.

The model may misunderstand a request, follow a malicious instruction embedded in retrieved content or select the wrong tool. A secure system assumes one of those failures can occur and limits what follows. Authentication, authorization, input isolation, policy checks and durable audit records belong outside the model.

NIST's 2026 analysis of AI agent security reports broad agreement that agents introduce novel security concerns and that existing cybersecurity practices need adaptation. The practical implication is not to replace normal security controls. It is to apply them at every point where probabilistic reasoning can influence data access or system state.

Start the threat model with four questions:

• What information can the agent observe?
• Which tools can it invoke?
• What state can those tools change?
• Which consequences are difficult to reverse?

An agent that summarizes a public document and an agent that issues refunds may use the same model. They do not have the same risk envelope.

Give every agent a bounded identity

An agent should not inherit a permanent administrator credential because a workflow might eventually need one privileged action. Give the runtime a distinct workload identity, bind each request to the initiating user or service and issue short-lived credentials for the specific task.

The authorization decision should be made by a policy-enforcement layer or the downstream system, not by asking the model whether an action seems permitted. The model may propose read_customer_record; the control plane resolves the tenant, user, resource, purpose and allowed fields before the call is executed.

The NIST concept paper on software and AI agent identity frames the open design questions around identification, authentication, authorization, delegation, auditing and non-repudiation. A useful production identity record therefore includes:

• the agent and workflow version;
• the human or service principal on whose behalf it acts;
• the approved purpose and current task;
• allowed tools, resources and data classifications;
• credential expiry and revocation state;
• the policy decision attached to every attempted action.

This makes delegated authority inspectable. It also lets the platform revoke one agent or task without rotating a shared secret used by unrelated workflows.

Treat retrieved content as untrusted data

Prompt injection is not limited to a user typing an adversarial prompt. An agent can encounter instructions inside an email, web page, support ticket, document, image or tool response. The content may look relevant to the task while attempting to redirect the agent, reveal data or trigger an unrelated action.

OpenAI describes modern prompt injection as a form of social engineering and argues that filtering suspicious strings is not enough. The system must constrain the impact even when manipulated content reaches the model. That means preserving the distinction between trusted instructions and untrusted evidence throughout the execution path.

Do not concatenate everything into one undifferentiated prompt. Mark source provenance, keep untrusted material in a separate data channel and prevent retrieved content from creating new permissions. When possible, use one component to inspect external information and another constrained component to prepare an action from a typed record.

A detector can still be useful as one signal. It should not be the only barrier between an email and a wire transfer, a production deployment or a customer-facing message.

Put policy between reasoning and action

Tool design determines the blast radius of an agent failure. Prefer narrow operations such as create_refund_draft(order_id, reason) over open-ended tools such as run_sql, execute_shell or call_any_url. Validate arguments against a schema, resolve authorization server-side and return bounded results.

OWASP describes excessive agency in terms of excessive functionality, permissions and autonomy. Its mitigations include minimizing available extensions, avoiding open-ended tools, enforcing downstream authorization and requiring approval for high-impact actions.

A practical control plane evaluates each proposed action using:

Make approvals specific and trustworthy

Human approval is valuable when it exposes the real consequence of an action. It is weak when the dialog repeats a model-written summary that may itself have been influenced by hostile content.

Build the approval view from validated tool arguments and trusted system data. Show the action, target, changed fields, destination, data leaving the organization and whether the operation can be reversed. Separate the agent's explanation from the authoritative transaction details.

Approval policy should follow impact, not uncertainty alone. A confident model can still propose a damaging action. A low-confidence model may propose a harmless read. Useful categories are:

• Automatic: bounded, read-only and observable operations.
• Review queue: reversible changes with a clear diff.
• Explicit approval: external communication, financial activity, permission changes or destructive operations.
• Prohibited: actions outside the product's defined authority, even if a user asks conversationally.

OWASP's analysis of deceptive human-in-the-loop dialogs shows why the approval surface must not inherit attacker-controlled presentation. The user should approve a normalized operation, not the agent's narrative about it.

Test the complete security envelope

A model refusal benchmark does not establish that an agent is secure. Evaluate the model, orchestration code, connectors, permission model, approval experience and downstream services together.

Create adversarial tasks from the actual workflow. Place conflicting instructions in documents and tool results. Attempt cross-tenant access, stale credential use, argument substitution, approval fatigue, recursive tool calls and data exfiltration through allowed channels. Include ordinary failure cases as well: ambiguous customer names, duplicate requests, timeouts and partially completed actions.

Record whether the system prevented the action, reduced its impact, requested an appropriate approval and left enough evidence for investigation. Logs should connect the initiating principal, agent version, retrieved sources, model and policy decisions, tool arguments, approval result and final side effect. Protect those records from alteration by the same agent being observed.

Incident response also needs an agent-specific stop path: revoke credentials, disable a tool or connector, pause the workflow, preserve traces and identify other runs that touched the same source or resource. This connects security work with AI evaluation and observability, rather than treating testing as a final launch gate.

Production readiness checklist

Before an enterprise agent receives write access, verify the following:

• Every agent and delegated task has an identifiable principal and expiring authority.
• Tools expose the minimum necessary operations and validate typed arguments.
• Downstream services enforce authorization independently of the model.
• Retrieved content cannot grant permissions or redefine the user's intent.
• Sensitive data and external destinations are checked before information leaves a boundary.
• High-impact approvals display trusted transaction details and a clear diff.
• Time, tool-call, cost and retry budgets stop runaway execution.
• Actions are idempotent where retries could duplicate side effects.
• Logs connect inputs, policy decisions, approvals and outcomes without exposing unnecessary secrets.
• Security evaluations cover indirect prompt injection and legitimate operational failures.
• Operators can revoke credentials and disable a capability without redeploying the entire product.

The objective is not an agent that never makes a mistake. It is a system in which one mistaken or manipulated decision cannot silently become unrestricted authority. For a scoped implementation, see Enterprise AI Agents and Agentic AI.