Does ‘AI security’ mean something different in 2026 than it did last year?

The change is real, but it is not a clean break

The following is a comparison of emphasis, not a claim that these threats first appeared in 2026 or that every organization has the same exposure. The 2026 OWASP LLM guide still places prompt injection first, but elevates excessive agency to third and treats supply chain, sensitive-data disclosure, hidden context exposure, retrieval, and output handling as linked system risks. Its rankings are a useful prioritization input, not a measurement of the likelihood or impact in your own environment. OWASP Top 10 for LLM Applications 2026

Prompt injection has not become “solved.” OpenAI’s 2026 guidance says the effective real-world cases increasingly resemble social engineering and argues for limiting the consequence of manipulation rather than relying on a filter to recognize every malicious input. OWASP likewise says prompt injection remains inherent to how generative systems process instructions and external content, so mitigation must include privilege control, deterministic validation, human approval, content segregation, and recurring adversarial tests. OpenAI: Designing AI agents to resist prompt injection · OWASP: Prompt Injection

The right operating model: one security program, with an AI extension

Use your existing cloud and application-security program as the control plane. In NIST CSF 2.0 terms, add AI-specific outcomes to Govern, Identify, Protect, Detect, Respond, and Recover rather than inventing a disconnected checklist. NIST CSF 2.0 overview

This distinction matters: a model is not a trustworthy policy-enforcement point. It can recommend an action, but trusted code should validate the target, arguments, authorization, data policy, and required human approval before anything happens. OWASP recommends holding credentials and state-changing capability in application code, limiting tool functionality and permissions, and applying human approval to high-risk operations. OWASP: Prompt Injection · OWASP: Excessive Agency

A useful risk test: the three-way combination

An agent deserves high scrutiny when it can simultaneously:

1. Consume untrusted content;
2. Access sensitive data; and
3. Communicate externally or make state changes.

Remove or tightly govern at least one of those capabilities. For example, a research agent may read public web content but have no private-data connector and no send/write tool. A finance-operations agent may access sensitive records but only use a narrow internal API, with a human approving each payment-related action. This is a way to prioritize architecture decisions—not a guarantee that systems outside the combination are safe. It follows the blast-radius logic in OWASP’s prompt-injection and excessive-agency mitigations. OWASP: Prompt Injection · OWASP: Excessive Agency

What to do about each important 2026 surface

1. Prompt injection and untrusted context

Direct prompts are only one delivery path. Indirect injection can arrive through a document, email, web page, support ticket, retrieved passage, tool result, or persistent memory. NIST’s 2025 taxonomy includes both prompt injection and indirect prompt injection; OWASP describes external files, websites, multimodal content, and connected functions as important delivery and impact paths. NIST AI 100-2e2025 · OWASP: Prompt Injection

Use several layers:

• Assign provenance and trust labels to every context source. Treat public and user-contributed content as untrusted even when it is retrieved from an otherwise familiar system.
• Constrain what enters the context window: retrieve the minimum relevant content, sanitize unsupported content formats, and do not persist model-generated instructions into long-term memory automatically.
• Use structured outputs and ordinary code to validate schemas, allowed operations, identifiers, and destinations. Schema validation helps with format; it does not prove the request is safe or intended.
• Design for a successful injection: it must still be unable to obtain broad credentials, bypass an egress policy, alter approval requirements, or call an unapproved operation.
• Use detection or filtering as a helpful signal, not the sole boundary. A filter that misses an adaptive attack should not turn into a privileged action.

2. Agent and tool authority

The defining operational change is agency: a model’s output can be routed into tools. Make the tool layer act like a transaction service, not a generic shell.

• Define tools around narrow business operations—such as “create a draft case for this customer”—rather than broad database, filesystem, or administrative access.
• Use default-deny allowlists for tool names, target systems, object types, and outbound destinations.
• Bind each tool call to a concrete principal, tenant, session, and purpose. Do not reuse one powerful integration identity for unrelated users and tasks.
• Reauthorize at execution time, after the model has proposed the exact arguments. A prior user login is not enough evidence that every later action is authorized.
• Require a human to review the rendered, exact action for irreversible, high-impact, or externally visible operations. The reviewer should see the target, material data to be shared, and resulting change—not a vague “approve agent action” prompt.
• Impose capability, rate, cost, recursion, and time budgets. They limit errors and abuse even when authorization is correct.

Concrete example: A support assistant may summarize a customer ticket and create a draft in the CRM using a task-scoped service identity. It should not be able to export the customer database or send mail to arbitrary recipients. If the ticket contains hostile text, the action broker still accepts only the drafted-case schema and the user’s authorized account; it rejects external-mail or bulk-export requests.

3. Identity, authorization, and data exfiltration

Use normal zero-trust principles, with more granular identity evidence:

• Prefer per-user or per-workload identities over shared provider keys. Make delegation explicit.
• Use short-lived credentials with minimal scopes, target-resource/audience binding, secure storage, rotation, and revocation. Record the actor, delegated subject, tool, scopes, target, approval, and decision.
• Authorize retrieval at query time and enforce tenant boundaries in the retrieval layer; do not rely on the model to “remember” who may see a document.
• Keep sensitive data out of prompts where a smaller derived value will do. Mask or tokenize fields, use approved data zones, and minimize persistence of histories and memory.
• Put outbound calls behind egress controls, destination allowlists, and data-loss rules. Watch for novel or unusually large transfers, newly enabled connectors, and cross-tenant results.

“Read-only” is not synonymous with low risk: an agent that can read private data and call any external URL may still disclose data. Conversely, a system that only retrieves approved public material and cannot communicate or change state can have a much smaller blast radius.

4. MCP and tool ecosystems

MCP is relevant when it is the mechanism connecting an AI client to tool servers, not because the protocol itself replaces IAM. It introduces recognizable security concerns—OAuth authorization, token storage, proxying, SSRF, stateless request routing, explicit application-state handling, consent, and third-party dependencies—into an AI-driven flow.

The current MCP authorization specification requires protected-resource discovery, issuer validation, least-privilege scope selection, and resource-bound authorization requests. Its security guidance forbids token passthrough and covers SSRF, confused-deputy, consent, and local-server risks. The 2026-07-28 core protocol is stateless; applications that need continuity should use explicit state handles rather than transport sessions. MCP Authorization specification · MCP Security Best Practices · MCP 2026-07-28 release

For an MCP deployment:

• Maintain an allowlisted registry of approved servers and tools, with an owner, purpose, data classification, permissions, network destinations, version/digest, review date, and disable switch.
• Use a separate token for each resource server. Validate issuer, audience, expiry, scopes, and recipient; never relay a received token to a downstream API.
• Pin and review server/tool packages and tool-descriptor changes. Treat a changed tool description, schema, or OAuth metadata as a material change that may require reauthorization and retesting.
• Use a hardened egress path for discovery and server access. Block private, link-local, and metadata-service destinations unless a reviewed use case requires them; validate redirects and DNS behavior.
• Show meaningful, per-operation consent. Permissioning a connector once should not silently authorize every future high-impact request.

Concrete example: An engineering assistant with an issue-tracker MCP tool may read a public issue that asks it to change deployment settings. The issue is evidence, not authority. The agent can propose a change request, but the deployment broker accepts only an approved workflow, with an environment-specific role and required human change approval. The MCP server receives an audience-bound token for itself—not an upstream cloud or source-control token.

5. Model and software supply chains

The AI supply chain includes more than the base model: model weights or APIs, adapters, prompts, embedding models, datasets, data-ingestion jobs, vector indexes, container images, libraries, tool servers, and CI/CD configuration. Apply normal supplier and software practices to all of them.

NIST SP 800-218A augments the Secure Software Development Framework with practices specific to generative AI and foundation models, and is intended for model producers, AI-system producers, and acquirers. NIST SP 800-218A · NIST SSDF

Minimum release discipline:

• Keep an inventory with exact model, provider/weight origin, embedding model, data source, prompt/template, tool/server, container, and policy version.
• Use approved artifact sources; verify signatures/checksums and provenance where available; scan packages and images; restrict build and release identities.
• Record who approved a new model, fine-tune, tool, connector, or retrieval corpus and what security evaluation was run.
• Promote through controlled environments. A model version that passes quality checks may still expand tool-selection, data-disclosure, or injection risk.
• Maintain a fast rollback or disable path. SLSA’s provenance model is useful for software artifacts because it lets consumers verify how an artifact was built and which inputs were used; it complements, rather than substitutes for, model-behavior evaluation. SLSA build provenance and levels

6. Evaluation, red-teaming, monitoring, and response

Model benchmarks alone are insufficient. Test the deployed system end to end, including the retrieval layer, tool broker, authorization service, network path, UI/approval flow, and observability pipeline.

Run a repeatable evaluation suite before release and after every material change: model or prompt version, new tool or MCP server, expanded scope, retrieval-corpus change, new memory behavior, identity-policy change, or network-egress change. Include:

• Indirect-injection tests using representative, safe test documents and tool responses;
• Attempts to cross tenant/user boundaries in retrieval;
• Unauthorized, malformed, or overbroad tool arguments;
• Attempts to make state changes or send data without the required approval;
• Token-audience, scope, expiration, redirect, and consent failures for integrations;
• Poisoned or unexpected RAG/memory entries;
• Rate, cost, retry, loop, and error-path tests;
• Tests where the evaluators know the deployed controls, not only a secret test prompt.

Measure outcomes that decision-makers can act on: prevented prohibited actions, unauthorized data access, egress-policy denials, policy-broker coverage, false approvals/false denials, time to disable a connector, and time to revoke delegated credentials. Do not publish an aggregate “prompt-injection safe” score; a system can resist a test string yet remain dangerous because it has unnecessary authority. OWASP recommends recurring adversarial testing together with least-privilege and human-approval controls that limit the blast radius of a successful manipulation. OWASP: Prompt Injection · OWASP: Excessive Agency

Log the minimum evidence needed to investigate safely: request/session ID, user and delegated identities, tenant, model and deployment version, retrieval document IDs and trust labels, policy decisions, tool name and validated arguments, scopes, destination, approval event, result, and timestamps. Protect logs themselves: prompts and tool results can contain secrets or personal data, so redact where feasible, restrict access, set retention, and retain a protected forensic path.

First-response runbook

1. Stop the affected capability: disable the tool/connector, route, model deployment, or egress path with the smallest safe blast radius.
2. Revoke and rotate the relevant delegated credentials, service identities, sessions, and API keys; preserve identity and authorization logs.
3. Preserve evidence under normal incident-handling rules, then determine which data sources, tool calls, recipients, tenants, and identities were actually involved.
4. Quarantine suspicious retrieval documents or persistent-memory entries; inspect related ingestion paths before restoring them.
5. Fix the failed deterministic control or reduce authority, reproduce the issue only in a safe test environment, and add it to the regression suite.
6. Notify owners, customers, regulators, or partners only under the organization’s established incident and legal process.

A practical 90-day implementation sequence

Small teams can start with a narrower alternative: a read-only, retrieval-limited assistant with no external tools or persistent memory. It provides less automation but is dramatically easier to reason about. Other viable options are a human-operated workflow where the assistant only drafts requests, or a first-party, narrow API adapter instead of a broad tool ecosystem. Choose the least autonomous design that achieves the business outcome.

Common failure modes

• Treating an “AI firewall” as the security boundary. Detection can help, but it cannot reliably distinguish data from malicious intent in every context. Make permissions, egress, and execution checks do the security-critical work.
• Giving the model a powerful, shared service account. This turns a manipulated plan into the application’s maximum privilege. Use task- and resource-scoped delegated authority instead.
• Assuming RAG makes content safe. RAG can retrieve the correct document and still bring untrusted instructions, stale content, or an unauthorized document into context.
• Trusting tools, descriptors, and registry metadata by default. Tool text and outputs are inputs; servers and packages are third-party dependencies.
• Approving a connector once, forever. Use incremental scope, explicit reauthorization for material changes, and approval at consequential action time.
• Logging every prompt and result without controls. This can create a new sensitive-data store and expand the incident scope.
• Red-teaming once before launch. AI behavior and connected-system risk change whenever the model, prompt, data, tool, identity policy, or network path changes.

Limitations and boundary conditions

No current control set can prove that an LLM will never follow an injected instruction. The defensible objective is to make a successful manipulation insufficient to access protected data or cause a prohibited effect. The right residual-risk threshold depends on the data, users, action authority, exposure, and recovery capability—not on whether the feature is branded “AI.”

This is security architecture guidance, not legal, medical, financial, or child-safety advice. Systems that make or materially influence legal, clinical, financial, employment, housing, education, or child-related decisions need applicable domain rules, privacy and recordkeeping analysis, validated human accountability, and a risk assessment beyond this article. Do not treat an agent’s output as the final authority in those settings.