Skip to content
IOmergent
Talk to us
Home Fractional CISO Managed Cloud Security Solutions Industries Resources About Talk to a CISO

AI Security Reference Architectures

How AI reaches a model, takes action and ships to your customers, in eleven diagrammed models from a single API key to an enterprise control plane.

TRACK AModel accessTRACK BAgent runtimesTRACK CAI you shipA1 Direct to Provider: One API key, straight to the vendor.A1Directone key, no visibilityA2 Workforce AI Apps: Employees using AI chat apps and the AI inside their SaaS.A2Workforce AIchat apps and SaaS AIA3 Gateway and Router: One choke point for keys, cost, routing and inspection.A3Gateway & Routerone choke pointA4 In-Boundary Inference: Inference stays inside your cloud or cluster.A4In-Boundaryinference in your cloudB1 Employee AI Agents: Agents that act with one employee's access, inside your AI tenant or outside it.B1Employee Agentsan employee's accessB2 Vendor-Run Agents: Agents a vendor runs with its own access to your data and systems.B2Vendor-RunAI SOC and SRE agentsB3 Agents You Build: Agents and AI workflows you run, with governed tool access.B3Agents You Buildworkflows and custom agentsB4 Developer AI: AI that writes, reviews and ships code.B4Developer AIcoding agents and CIMODELSModel providersfrontier, cloud, self-hostedTOOLSTools & dataSaaS, APIs, cloudC1 Customer Agents on Your API: Your customers' AI agents calling your product.C1Customer agentsagents on your APIC2 AI Features in Your Product: AI your customers use inside your product.C2Product AIAI in your productCUSTOMERSYour customerstheir users and agentsT Enterprise Reference: Every track under one control plane, from vendor tenants to the AI you ship.T · TARGET STATEEnterprise Reference: every track under one control plane, from vendor tenants to the AI you shipCOMBINEDTarget stateLESS CONTROLMORE CONTROL
FlowsPrompt / responseTool callIdentity / credentialTelemetryUnsafe pathBlocked
BoundariesYour boundaryThird party

Track A: Model access

How prompts reach a model. Ordered from least to most control.

A1

Direct to Provider

Owner: Individual devsControl: LowHours to 2 wks

Seed or Series A teams moving fast. The default for most engineering teams.

Implementation guide: products, build vs buy and rollout steps
Your environmentThird party, public internet1234ACTORDeveloperIDE, CLI, scriptsWORKLOADDev machinelaptop or VM, with EDRSECRETS.env / env varsstatic, long-lived keySIMPLIFYMODELOpenAI APIGPT modelsMODELAnthropic APIClaude modelsTELEMETRYVendor consolesusage only, per vendorKEEP

Data flow

  1. 1Developer runs code or an agent with a vendor SDK on a laptop, a local or cloud VM, or a dev container.
  2. 2A static API key is read from a .env file, a shell variable or a Codespaces secret. EDR on the machine is the main defense against infostealers that harvest these files.
  3. 3Prompts, code and context go straight to each provider over the public internet.
  4. 4Only per-vendor usage and billing is visible. There is no central prompt log, and per-user attribution needs per-user keys.

Common use cases

  • Prototypes and spikes
  • Individual dev productivity
  • Hackathons and demos

Key risks

  • Keys copied across projects and laptops
  • No inspection of what data leaves
  • Shared keys hide who spent what
  • Spend caps only per project or workspace, not per key

Fast path

  • KEEPSpend cap on every project or workspace
  • SIMPLIFYKeys that expire, one project per app
  • SIMPLIFYDevelopers sign in to Claude Code or Codex with their SSO seat, no key
  • SIMPLIFYKeys in a password manager CLI such as 1Password, not .env files
  • DEFEREverything else. This is already the fast path.
A2

Workforce AI Apps

Owner: IT + securityControl: Low to MedDays to 3 mos

Every company. Most AI use starts here, often on personal accounts before anyone approves a tool. Two variants: AI chat apps people choose, and the AI features and agents inside the SaaS you already pay for.

Implementation guide: products, build vs buy and rollout steps
2 variants
A2.1Chat appsEmployees pick an AI chat app or desktop assistant.
Your environmentApproved AI vendor tenant12345×78ACTOREmployeeschat, desktop, browsersCONTROLEDR AI module or proxydiscovery, monitor firstKEEPCONTROLMDMJamf, Iru or IntuneKEEPIDENTITYOkta, Entra or GoogleSSO, managed devices onlyKEEPMODELEnterprise AI tenantno training on your dataKEEPTOOLSConnectorsDrive, Slack, emailTELEMETRYAudit log APIexport to bucket / SIEMSIMPLIFYRISKShadow AIpersonal and unknown AI

Data flow

  1. 1Employees use AI chat apps, desktop assistants and AI browsers for everyday work.
  2. 2MDM locks Claude Desktop to your company account, pushes browser policies and, where needed, your EDR vendor's AI extension, and blocks unapproved AI apps and AI browsers.
  3. 3MDM reports device compliance to the IdP, so only managed devices can sign in to the work AI tenant.
  4. 4SSO and a verified domain put work accounts in the company tenant. If you run Cloudflare or an SSE with TLS inspection, it adds tenant headers that block personal Claude and ChatGPT accounts in the browser. OpenAI doesn't document the header in its desktop apps.
  5. 5Approved use reaches the company tenant. The EDR AI extension or the proxy's DLP redacts or blocks sensitive data in browser prompts and reports AI use to your EDR console and MDR. Desktop app coverage is limited.
  6. 6Unapproved AI tools are found and blocked by MDM, the EDR module or the proxy. Personal accounts on approved sites need the proxy's tenant headers.
  7. 7Connectors let the assistant read and act in Drive, Slack and email with the user's own permissions.
  8. 8On Enterprise tiers, the vendor's audit or compliance API exports chats and admin events. ChatGPT keeps them 30 days, so pull at least weekly.
A2.2AI inside your SaaSAI features and agents inside the SaaS you already pay for: Microsoft 365, Slack, Zoom, Notion, the CRM, and the agents makers build in suites such as Copilot Studio or Agentforce.
SaaS vendor tenant12345678×10ACTOREmployeesMicrosoft 365, Slack, CRMACTORLow-code makersCopilot Studio, AgentforceMODELVendor AI modelor its AI subprocessorWORKLOADSaaS AI and agentsfeatures, embedded agentsIDENTITYOkta, Entra or GoogleSSO, AI feature groupsKEEPCONTROLVendor admin planeAI toggles, DLP, connectorsKEEPCONTROLData governancelabels, fix oversharingKEEPTOOLSYour data in the SaaSfiles, messages, recordsTOOLSConnectorsthird-party actionsRISKNotetaker botsauto-join and consentTELEMETRYVendor audit logexport to bucket / SIEMSIMPLIFY

Data flow

  1. 1Employees use AI features and agents inside tools they already pay for: Microsoft 365 Copilot, Slack, Zoom, Notion, the CRM.
  2. 2Makers build and publish agents in low-code studios such as Copilot Studio or Agentforce, often with no security review.
  3. 3SSO groups decide who gets each AI feature or agent, where the product supports it. Many only offer a workspace-wide toggle.
  4. 4Prompts and content go to the vendor's model or its AI subprocessor, under the vendor's data terms.
  5. 5Governance lives in each vendor's admin plane: AI toggles, retention, excluded channels and spaces, DLP, connector allowlists and environment rules.
  6. 6The feature or agent answers with whatever the user can already reach, so old oversharing becomes instant exposure.
  7. 7Connectors let agents act in third-party systems, and can run on the maker's own credentials unless policy blocks it.
  8. 8Data governance labels sensitive content and removes broad sharing, so AI search can't surface it. Auto-labeling needs E5 or E5 Compliance.
  9. 9Notetaker bots your users install are blocked from auto-joining. Waiting rooms and authenticated join stop outside attendees' bots, and recording follows all-party consent rules.
  10. 10Vendor audit logs show AI feature and agent use, often on the top tier only. Microsoft 365 export is included; Salesforce needs a paid add-on. Export before the retention window ends.

Common use cases

  • Writing and research
  • Meeting notes and summaries
  • AI browsers acting on web pages
  • Helpdesk and CRM agents built in Copilot Studio or Agentforce

Key risks

  • Sensitive data pasted into personal accounts
  • Shadow AI tools with unknown data terms
  • AI features switched on by default in existing SaaS
  • Notetakers recording meetings without consent
  • AI browsers following instructions hidden in web pages
  • Oversharing surfaced instantly by AI search
  • Suite agents running on a maker's own credentials

Fast path

  • KEEPEnterprise tenant with SSO and no training on your data
  • KEEPMDM locks Claude Desktop to your org and blocks unapproved AI apps
  • KEEPReview the AI settings in every SaaS admin console
  • SIMPLIFYWritten acceptable use policy before a browser control
  • DEFERProxy tenant headers and prompt blocking until a few weeks of monitor mode
  • KEEPFix oversharing on top sites before turning on AI search or agents
  • KEEPBlock maker credentials in suite connectors
  • SIMPLIFYWeekly audit log export to a bucket
A3

Gateway and Router

Owner: Platform engControl: Med to Med-HighDays to 6 wks

Series B to mid-market with several teams using AI. Two variants: self-hosted or managed. An aggregator such as OpenRouter is a managed gateway that also sells you the model access.

Implementation guide: products, build vs buy and rollout steps
2 variants
A3.1Self-hostedYou run the gateway in your cloud. Most control, most to operate.
Your cloudModel providers123456WORKLOADInternal apps & chatvirtual key per teamWORKLOADDev containersvirtual key per devCONTROLGuardrails / DLPPII, secrets, injectionDEFERCONTROLAI GatewayLiteLLM, Kong, EnvoySIMPLIFYIDENTITYOkta, Entra or GoogleSSO, group claimsKEEPTELEMETRYLogs to SIEMuser, model, tokens, costSIMPLIFYSECRETSSecrets managerprovider master keysKEEPMODELOpenAIMODELAnthropicMODELGoogle Gemini

Data flow

  1. 1Apps and dev containers call one OpenAI-compatible endpoint with a virtual key.
  2. 2The gateway maps each key to a user or team through SSO groups for quotas and chargeback.
  3. 3Guardrails check app and chat prompts for PII, secrets and injection before anything leaves. Coding-agent traffic is too large to scan economically.
  4. 4The gateway pulls real provider keys from the secrets manager. Teams never see them.
  5. 5Requests route to the right provider with fallback, rate limits and budgets.
  6. 6Every request logs user, model, tokens, cost and guardrail verdict.
A3.2Managed or aggregatorA gateway vendor runs it. Live in a day, one more vendor in the path. An aggregator such as OpenRouter is the same pattern, but it also sells you the model access.
Your cloudGateway vendorModel providers123456WORKLOADInternal apps & chatgateway token per teamWORKLOADDev containersgateway token per devIDENTITYOkta, Entra or GoogleSSO to gateway consoleKEEPCONTROLVendor guardrailsPII, injection filtersDEFERCONTROLManaged gatewayCloudflare, Prisma AIRS, OpenRouterTELEMETRYVendor log storeexport to bucket / SIEMSIMPLIFYSECRETSProvider keysBYOK or vendor-storedKEEPMODELOpenAIMODELAnthropicMODELGoogle Gemini

Data flow

  1. 1Apps and dev containers call the vendor's endpoint with a per-team gateway token.
  2. 2SSO, usually on enterprise tiers, controls who can manage keys, routes and budgets in the gateway console.
  3. 3Vendor guardrails inspect prompts if enabled.
  4. 4Provider keys live with the vendor, or stay yours with bring-your-own-key. An aggregator such as OpenRouter replaces your provider contracts with its own: one key and one bill for hundreds of models, and BYOK changes the billing, not the data path.
  5. 5The gateway handles routing, caching, fallback and rate limits. An aggregator also picks among upstream providers with different retention terms, so require ZDR and a provider allowlist on the account. OpenRouter publishes no BAA, so keep PHI off it.
  6. 6Logs sit in the vendor's store. Export them to your bucket or SIEM.

Common use cases

  • Internal chat and assistants
  • Shared API access across teams
  • Cost attribution and chargeback
  • Model evaluations and provider failover

Key risks

  • Gateway outage stops all AI traffic
  • Gateway logs hold sensitive prompts
  • Bypass if teams keep direct keys
  • Aggregators add a subprocessor with variable retention and no BAA
  • Routing through a gateway can fall outside a vendor's BAA

Fast path

  • SIMPLIFYManaged gateway instead of self-hosting
  • DEFERPrompt DLP. Use ZDR terms and a data policy first
  • SIMPLIFYBucket with retention before SIEM
  • KEEPProvider keys only in a secrets manager or BYOK
  • KEEPPinned, signed gateway images, never unpinned pip installs
  • KEEPZDR and provider allowlist on any aggregator
A4

In-Boundary Inference

Owner: Platform eng + cloud teamControl: High to Highest2 wks to 4 mos

Regulated, residency-bound or IP-sensitive orgs. Two variants: a managed cloud AI service, or open-weight models you run.

Implementation guide: products, build vs buy and rollout steps
2 variants
A4.1Managed cloud AIThe cloud runs the model inside its compliance boundary. You get IAM identity and private networking.
Your VPC, private subnetsCloud AI service123456ACTOREmployeesvia SSOIDENTITYWorkload identityIAM role, no static keysKEEPWORKLOADWorkload (EKS / ECS)RAG app, doc processorWORKLOADVector DB / dataPHI stays in regionCONTROLPrivateLink endpointno internet egressKEEPTELEMETRYCloudTrail + logsinvocations to SIEMSIMPLIFYCONTROLProvider guardrailsBedrock Guardrails etc.DEFERMODELManaged modelsBedrock, Foundry, Agent Platform

Data flow

  1. 1Users sign in to an internal app.
  2. 2The workload gets short-lived credentials from its IAM role. No API keys exist.
  3. 3Retrieval pulls sensitive context from data stores inside the VPC.
  4. 4Model calls go through a PrivateLink endpoint, never the public internet. In-region inference profiles keep data in region.
  5. 5Provider guardrails filter each invocation inside the cloud's compliance boundary (BAA, FedRAMP, region).
  6. 6Invocation logging is off by default and misses Bedrock's newer mantle endpoint, so turn it on, and keep apps on bedrock-runtime or log in the app. With CloudTrail, both land in your account and stream to the SIEM.
A4.2Self-hosted open weightsYou run the models on GPUs you own. Nothing leaves, and you own everything.
Your cluster, egress denied1234×6ACTORUsers & appsvia SSOWORKLOADBatch & code jobsrepo scans, doc runsCONTROLInternal gatewayauth, quotas, routingSIMPLIFYTELEMETRYCluster logsforward to SIEMSIMPLIFYWORKLOADInference serversvLLM on GPU nodesCONTROLModel registryscanned, signed, pinnedKEEPRISKPublic internetall egress deniedMODELHugging Face / vendoropen-weight models

Data flow

  1. 1Users and batch jobs call one internal, OpenAI-compatible endpoint.
  2. 2The gateway handles SSO, quotas and routing to the right model size.
  3. 3New open-weight models are imported deliberately, never pulled at runtime.
  4. 4The registry scans, signs and pins versions before GPU nodes load them. Scanners catch malicious files, not backdoored weights, so evaluate each new model.
  5. 5Outbound internet is denied, so prompts and outputs never leave the cluster. Offline settings let the stack start without it.
  6. 6Gateway and inference logs stay in-cluster and forward to the SIEM.

Common use cases

  • PHI and PII document processing
  • Regulated customer support bots
  • Source code and IP analysis
  • Residency-bound or air-gapped workloads

Key risks

  • Model catalogs differ by cloud
  • Invocation logging off by default, with gaps on newer endpoints
  • Malicious or backdoored open weights
  • You own GPU capacity and every serving-stack CVE

Fast path

  • KEEPIAM roles, no static keys
  • KEEPSeparate cloud account for PHI AI workloads
  • KEEPPrivate networking or egress deny
  • KEEPInvocation logging on, plus app-level logs
  • KEEPRegistry with scanning and pinning (self-hosted)
  • DEFERProvider guardrails at launch
  • SIMPLIFYLogs to bucket before SIEM

Track B: Agent runtimes

How AI takes action. Ordered from least to most control. Employee and vendor-run agents run on someone else's platform, so the controls are grants, settings and your own logs. Agents you build and coding agents call a Track A model and reach tools through the toolshed: an MCP gateway that holds the approved tool list, issues short-lived on-behalf-of (OBO) tokens and logs every call (B3).

B1

Employee AI Agents

Owner: IT + securityControl: Low to MedDays to 8 wks

Every company. People hand agents their own access: agent mode and connectors in ChatGPT, Claude, Copilot or Gemini, AI email apps granted their mailbox, OpenClaw on a laptop, coding agents on a personal device. The agent can do whatever that person can, so the controls are which actions it may take, which grants it may hold and which devices it may run on. Two variants: inside your enterprise AI tenant, and outside it. When the agent has its own access rather than one person's, see B2.

Implementation guide: products, build vs buy and rollout steps
2 variants
B1.1In your AI tenantAgent mode, browser control and connectors inside your enterprise AI tenant. The vendor runs the agent; you decide what it can reach.
Enterprise AI tenantCompany data12345678ACTOREmployeedelegates a taskRISKUntrusted contentemail, invites, docs, webCONTROLTenant agent settingsagent mode, sites, memoryKEEPWORKLOADVendor agentChatGPT, Claude, CopilotIDENTITYOkta, Entra or GoogleSSO, agent access by groupKEEPCONTROLLabels + DLPkeep labeled data outDEFERCONTROLConnector settingsper app, read-only firstKEEPACTORUser approvalsend, share, buy, deleteTOOLSEmail & calendarGmail, OutlookTOOLSFiles & chatDrive, SharePoint, SlackTELEMETRYAgent audit logexport to bucket / SIEMSIMPLIFY

Data flow

  1. 1An employee hands the agent a task: triage the inbox, book a meeting, research a vendor and fill in a form. The agent runs in the vendor's cloud or in the browser, as that employee.
  2. 2SSO groups decide who gets agent features. ChatGPT Enterprise assigns agent mode by role, and Claude Enterprise and Microsoft 365 by group. On Claude Team, Cowork is one switch for the whole org.
  3. 3Tenant settings decide what the agent may do: agent mode and browser use, site allow and block lists, memory, and scheduled or event-triggered tasks. Defaults differ. Agent mode is off in ChatGPT Enterprise, Claude in Chrome and Cowork are on for Team and Enterprise, and Copilot Cowork's browser use is off.
  4. 4The agent acts through connectors with the user's own access. Admins enable each connector, start read-only, and turn on write actions such as send, share and delete per app.
  5. 5Sensitivity labels and DLP keep labeled files and email out of what the agent reads, where the vendor supports it. Microsoft Purview does this for Copilot; most other vendors have no equivalent.
  6. 6Anything the agent reads is untrusted. An email, a calendar invite, a shared doc or a web page can carry instructions. EchoLeak in Microsoft 365 Copilot and Zenity's Claude in Chrome account takeover both started with an email.
  7. 7The agent asks the user before high-impact actions such as sending, sharing, buying or deleting. That prompt is the vendor's control, not yours: users can switch to automatic approval, and few admin consoles can force it back on.
  8. 8Logs record the session and, on some products, each action. Purview logs every item Copilot reads or changes and flags suspected injection. ChatGPT's Compliance API keeps agent conversations but not the agent's individual actions.
B1.2Outside your tenantThird-party AI apps granted the mailbox, open-source agents such as OpenClaw, and coding agents on laptops you don't manage. They get in through grants and tokens, so the controls sit at those doors.
Laptops1×34×6WORKLOADAI email and agent appsFyxer, Superhuman, LindyWORKLOADLocal agentsOpenClaw, Claude CodeRISKPersonal tokensOAuth, PATs, API keysIDENTITYDevice-aware SSOmanaged devices onlyKEEPCONTROLMDM + EDRfind and remove agentsKEEPCONTROLConsent + token policyadmin approval, scopesKEEPTOOLSEmail & calendarGmail, OutlookTOOLSFiles & chatDrive, SharePoint, SlackTOOLSGitHub, CRM, cloudrepos and consolesTELEMETRYGrant + token audittoken logs, SaaS detectionSIMPLIFY

Data flow

  1. 1AI email apps and agent platforms ask for OAuth access to the mailbox, calendar and files, often read, compose and send, and keep the refresh token on their servers.
  2. 2Local agents such as OpenClaw or Claude Code on a laptop you don't manage try the employee's SSO session. Device checks refuse a new session from an unmanaged device, but they don't stop tokens issued earlier.
  3. 3So those agents run on OAuth app tokens, personal access tokens and API keys stored on the laptop.
  4. 4Consent and token policy decide what any of these can reach. Google Workspace limits Gmail and Drive's high-risk scopes to trusted apps, Entra's managed consent stops users granting mail and file scopes, and GitHub can block classic PATs and set a maximum lifetime for fine-grained tokens, such as 90 days.
  5. 5On managed laptops, MDM and EDR find and remove unapproved local agents: CrowdStrike's OpenClaw removal pack, Jamf detection scripts, Intune. Local agents load community skills, and Koi Security found 341 malicious skills on ClawHub. On unmanaged laptops, the approved place to run agents is a cloud dev environment such as Codespaces or Coder.
  6. 6Google's OAuth token audit log, Entra consent records and SaaS security tools show which app holds which scopes and flag token use from unknown places. Review new grants weekly and revoke per app per user, including at offboarding.

Common use cases

  • Inbox triage and drafted replies
  • Scheduling, research and form filling in the browser
  • Recurring tasks that run while the user is away
  • Coding agents on personal and contractor laptops

Key risks

  • Instructions hidden in email, invites or web pages steer the agent
  • The agent sends, shares or deletes as the user
  • Broad OAuth scopes granted to third-party apps
  • Long-lived tokens on devices you can't see
  • Malicious skills and plugins on local agents
  • Agent memory and history outside your retention rules

Fast path

  • KEEPAgent mode and browser control for a pilot group first
  • KEEPRead-only connectors first. Write actions per app and use case
  • KEEPAdmin approval for apps asking for mail, calendar or file scopes
  • KEEPCompliant device required for source code and sensitive SaaS
  • KEEPMDM blocks unapproved local agents such as OpenClaw
  • KEEPOffboarding runbook that revokes tokens and sessions
  • SIMPLIFYWeekly OAuth grant review before a SaaS security tool
B2

Vendor-Run Agents

Owner: Security + platform engControl: Med1 to 6 wks

Companies that buy an AI SOC analyst or an AI SRE or on-call agent. The vendor runs the agent and holds standing access to your EDR, identity provider or cloud, so one stolen vendor token reaches the whole company. You control the grant, approval for actions and your own record of what it did. Agents inside a business suite such as Copilot Studio sit with the rest of that SaaS in A2.

Implementation guide: products, build vs buy and rollout steps
Vendor platformYour systems12345678ACTORAlerts and incidentsEDR, SIEM, pagerRISKAttacker-controlled datalog fields, hostnames, emailMODELVendor's modelsnamed subprocessorsWORKLOADVendor AI agentAI SOC or AI SRESECRETSCredentials at vendorAPI clients, tokens, rolesACTORAnalyst approvalcontain, disable, roll backKEEPCONTROLScoped accessread-only by defaultKEEPCONTROLAccess findingsAccess Analyzer, token zonesSIMPLIFYTOOLSEDR and SIEMCrowdStrike, SentinelOneTOOLSIdentity providerOkta, Entra, GoogleTOOLSCloud accountsAWS, Azure, GCPTELEMETRYYour own logsCloudTrail, Okta, EDR auditKEEP

Data flow

  1. 1An alert, incident or page goes to the vendor's agent, which investigates on its own and writes up a verdict.
  2. 2The agent reads data an attacker can write: log fields, hostnames, email subjects, user agents. 2026 research showed injected log entries suppressing detections in an AI analyst, and the best defense tested cut that rate by about half.
  3. 3Investigation data goes to the vendor's model providers. Check the named subprocessors, no-training terms, retention and region before you connect anything.
  4. 4The vendor stores the keys to your systems: EDR API clients, identity provider tokens, a cloud role. Stolen vendor tokens were the way in for the Salesloft Drift breach in 2025 and the Klue breach in 2026.
  5. 5Grant read-only scopes for investigation, through a dedicated role, service app or API client per vendor. Prefer an AWS role with read-only policies over access keys, and an Okta OAuth service app with one-hour tokens over an API token that inherits an admin's rights.
  6. 6Response actions such as isolating a host, suspending a user or revoking sessions use a separate write integration, with each action turned on one by one and an analyst approving it. Some, like revoking sessions, can't be undone.
  7. 7Every call the agent makes lands in your own logs: CloudTrail, the Okta System Log, the EDR's API audit. Alert on what it does from your side, not only in the vendor's console.
  8. 8AWS IAM Access Analyzer flags roles that outside accounts can assume, and Okta network zones limit where an API token works. Entra Conditional Access for workload identities doesn't cover multitenant vendor apps.

Common use cases

  • Alert triage and investigation
  • Incident response with containment actions
  • On-call root cause in cloud and Kubernetes
  • Agents acting in your identity provider and cloud

Key risks

  • Stolen vendor tokens reach every connected system
  • Write scopes granted for read-only work
  • Attacker-written log data steers the analyst
  • Response actions that can't be undone
  • Investigation data kept by the vendor and its model providers

Fast path

  • KEEPRead-only integration first, write actions added one at a time
  • KEEPA dedicated role, service app or API client per vendor, never an admin's token
  • KEEPAnalyst approval for containment and account actions
  • KEEPYour own logs of every vendor call, not just the vendor's console
  • SIMPLIFYQuarterly review of vendor roles and tokens before an inventory tool
B3

Agents You Build

Owner: Platform eng + buildersControl: Med to HighDays to 6 mos

Companies building agents or AI workflows that take actions, from an ops team's n8n flows to product engineering's custom agents. You run the runtime, so you can put the toolshed in front of every tool call. Two variants: low-code workflows, where the credential store is the risk, and custom agents, where identity and tool scoping are the hard part.

Implementation guide: products, build vs buy and rollout steps
2 variants
B3.1Low-code workflowYou host the engine, so its credential store holds the keys to everything it touches.
Self-hosted instance123456ACTORTriggerswebhooks, schedules, formsACTORWorkflow buildersops, RevOps, SecOpsIDENTITYSSO / private accesseditor never publicKEEPWORKLOADWorkflow enginen8n, Dify, LangflowTELEMETRYExecution historyforward to SIEMSIMPLIFYSECRETSCredential storeOAuth tokens for all appsKEEPMODELModel accessTrack A, via AI gatewaySIMPLIFYTOOLSCRM, email, SlackTOOLSCloud & ticket APIs

Data flow

  1. 1Workflows start from webhooks, schedules or forms. Those paths must be public and the input is untrusted, so patch within days and put a WAF in front.
  2. 2Builders reach the editor only through SSO (paid tiers) or a private-access proxy. Never expose it to the internet.
  3. 3LLM nodes call a Track A model, ideally the AI gateway for keys and logs.
  4. 4The same workflow then acts on CRM, email, Slack, cloud and ticketing APIs.
  5. 5Every connected app's OAuth token sits in one credential store. In n8n, a vault integration is Enterprise-only, so protect the encryption key and database.
  6. 6Execution history holds prompts and data. In n8n, native log streaming is Enterprise-only, so export it on a schedule.
B3.2Custom agents
Agent platformSystems of record12345678910ACTOREnd userchat, Slack, ticketIDENTITYIdPuser + agent identityKEEPCONTROLRed team & evalsCI gate before releaseSIMPLIFYMODELModel accessTrack A, via AI gatewayWORKLOADAgent runtimeplanner + LLM loopWORKLOADCode sandboxephemeral, no networkSIMPLIFYACTORHuman approvalexternal or destructiveKEEPCONTROLMCP gatewayregistry, OBO, scansCONTROLPolicy engineOPA / CedarSIMPLIFYTOOLSInternal APIsTOOLSSaaS (CRM, ticketing)TOOLSCloud APIsTELEMETRYTool audit to SIEMcall, args, resultSIMPLIFYCONTROLKill switchrevoke now, monitor laterKEEP

Data flow

  1. 1A signed-in user asks the agent to do something. The user's identity travels with the request.
  2. 2The agent plans with a Track A model, reached through the AI gateway.
  3. 3Generated code runs in an ephemeral sandbox with no network and no secrets.
  4. 4Every tool call goes to the MCP gateway, never directly to a system.
  5. 5The policy engine allows or denies per user, agent, tool and action.
  6. 6External, financial, destructive and regulated-data actions pause for human approval. Internal writes run on their own and are logged.
  7. 7The gateway gets a short-lived, narrowly scoped token for the user (on-behalf-of for internal APIs, stored per-user tokens for most SaaS, STS for cloud), calls the tool, and flags likely injected instructions in the result.
  8. 8Every call, argument and result is logged to the SIEM.
  9. 9Before each release, automated red teaming and evals test the agent for injection, data leaks and unsafe actions.
  10. 10A kill switch revokes the agent's tokens at once. A runtime monitor that flags anomalies can come later.

Common use cases

  • Lead enrichment and alert triage workflows
  • Onboarding and scheduled reporting
  • Customer-facing support agents
  • Ops and SRE runbook automation

Key risks

  • One credential store holding tokens for everything
  • Internet-exposed, under-patched workflow editors
  • Excessive agency from broad tool scopes
  • Confused deputy when the agent uses its own credentials
  • Prompt injection via tool results
  • No way to stop an agent that goes wrong

Fast path

  • KEEPSSO or private access in front of every workflow editor
  • KEEPPatch within days, WAF on public trigger paths
  • SIMPLIFYStatic tool allowlist per agent before OPA
  • KEEPHuman approval on external and destructive actions
  • KEEPShort-lived, scoped tokens per user
  • KEEPKill switch that revokes agent tokens
  • SIMPLIFYRedacted audit to a bucket first
B4

Developer AI

Owner: Eng + DevExControl: Med to HighDays to 4 mos

Engineering teams using AI across the SDLC. Two variants that share one control set: attended work in the IDE plus bots in CI, and autonomous background agents.

Implementation guide: products, build vs buy and rollout steps
2 variants
B4.1Attended and CIA developer drives the assistant in the IDE, and bots review pull requests in CI. The org sets the guardrails through managed settings and GitHub controls.
Developer workstation123456789ACTORDeveloperapproves each actionTELEMETRYSession telemetryEDR + OTel to SIEMSIMPLIFYMODELModel accessTrack A, via AI gatewayWORKLOADIDE / CLI assistantCursor, Copilot, ClaudeCONTROLManaged settingsvia MDM: permissions, MCPKEEPCONTROLEDR + inventoryAI module, MCP, skillsSIMPLIFYTOOLSApproved MCP toolsfrom the toolshedTOOLSLocal repo + shellno prod creds on boxKEEPTOOLSGitHubPRs through reviewWORKLOADCI botsOIDC, no fork secretsKEEP

Data flow

  1. 1The developer drives the assistant and approves actions as it works.
  2. 2Org-managed settings, delivered through MDM, fix the permission mode, allowed commands and which MCP servers can load. Server-side settings are skipped once a custom gateway URL is set.
  3. 3Model calls go through the AI gateway, not personal keys. For PHI, check BAA scope first: Claude Code's HIPAA setup excludes the IDE extensions, and Anthropic's pages indicate LLM gateways aren't covered.
  4. 4The assistant edits the local repo and runs commands. No prod creds live on the machine. Dev secrets come from a password manager CLI such as 1Password, from a vault that holds only low-privilege credentials.
  5. 5Only toolshed MCP servers are available: the approved list behind the MCP gateway (see B3).
  6. 6Changes ship as pull requests through normal review.
  7. 7Session telemetry and EDR feed the SIEM.
  8. 8Your EDR's AI module and endpoint inventory tools find local MCP servers, IDE extensions, skills and rules files. MCP servers and extensions can be blocked; skills and rules files can only be detected.
  9. 9Pull requests also trigger CI bots that review code and suggest fixes. The job signs in to the model with job-scoped OIDC, fork PRs run with no secrets, and the bot can only comment or push to a bot branch. GitHub settings and CODEOWNERS, not the bot's prompt, keep it from approving or merging.
B4.2Autonomous fleetAgents work tickets unattended in sandboxes. The merge gate is the control that matters most. Vendor-hosted agents are the fast path; self-hosting the fleet is 8 to 16 weeks of custom work.
12345678ACTORDeveloperassigns a ticketTELEMETRYSession auditcommands, reads to SIEMSIMPLIFYMODELModel accessTrack A, via AI gatewayWORKLOADCoding agentephemeral sandbox per taskSIMPLIFYIDENTITYOIDC + GitHub Appone repo, 1 hr tokensKEEPCONTROLEgress allowlistall else deniedKEEPTOOLSGitHubbranch protection onCONTROLCI + merge gatetests, scans, human reviewKEEPTOOLSApproved toolshedallowlisted MCP onlyTOOLSPackage registriesvia package firewallTOOLSUntrusted contentissues, deps, webWORKLOADProductiondeploys from CI only

Data flow

  1. 1A developer assigns a ticket. The agent starts in a fresh sandbox that is destroyed when the task ends.
  2. 2Credentials come from OIDC and a GitHub App, scoped to one repo. GitHub App tokens last one hour and can be revoked early.
  3. 3Model calls go through the AI gateway for logging, DLP and budgets.
  4. 4Issues, dependencies and web content are treated as untrusted data.
  5. 5The agent can only open a pull request. Branch protection blocks direct pushes.
  6. 6CI runs tests, secret scanning and SCA. A human approves before merge and deploy.
  7. 7Only allowlisted MCP tools from the toolshed are available.
  8. 8Egress is limited to the gateway and registries behind a package firewall. Every command and file read is logged.

Common use cases

  • Pair programming in the IDE
  • PR review and test generation in CI
  • Dependency upgrades and migrations
  • Backlog tickets worked unattended

Key risks

  • Injection via issues, READMEs and dependencies
  • Malicious MCP servers, extensions, skills and rules files
  • Secrets exposed to fork or untrusted CI runs
  • Reviewer time on bot PRs, which can cost more than the tools
  • Token scope creep across repos

Fast path

  • SIMPLIFYPersistent dev container for trusted repos only, with no prod creds and allowlisted egress
  • KEEPShort-lived scoped tokens (GitHub App, OIDC)
  • KEEPBranch protection and human review
  • KEEPNo secrets on fork or untrusted runs
  • SIMPLIFYSession and job logs to bucket first

Track C: AI you ship

AI your customers use: their agents calling your product, and AI features inside it. Ordered from least to most control. Both call a Track A model and reuse the same gateways and toolshed.

C1

Customer Agents on Your API

Owner: Platform eng + securityControl: Med to High2 to 12 wks

B2B SaaS whose customers connect AI agents to your API or an MCP server you publish. You don't control the agent, so you control what it can reach.

Implementation guide: products, build vs buy and rollout steps
Customer's environmentYour platform1234567WORKLOADCustomer's agentClaude, ChatGPT, customCONTROLAPI / MCP gatewayauth, rate limitsKEEPIDENTITYYour OAuth serverconsent, scoped tokensKEEPCONTROLConfirm stepout-of-band, per actionKEEPWORKLOADYour MCP serverscoped, read-first toolsKEEPCONTROLClient allowlistCIMD, pre-registeredKEEPTOOLSYour services & dataper-tenant scopesTELEMETRYAgent activity logper client and tenantSIMPLIFY

Data flow

  1. 1A customer's AI agent calls your API or MCP server on behalf of one of their users.
  2. 2Your OAuth server issues scoped, short-lived tokens after the user consents. Agents never get long-lived API keys.
  3. 3An allowlist of client ID metadata documents (CIMD) decides which agent apps may ask for tokens. Open dynamic registration stays off.
  4. 4The gateway checks every token and rate-limits per client. The MCP server, not the gateway, validates tool arguments.
  5. 5Your MCP server exposes a small set of scoped tools, read-only first, and reaches your services only within the user's tenant and scopes.
  6. 6Writes and destructive actions need the user's confirmation outside the agent, tied to that exact action.
  7. 7Every call is logged per client and per tenant, so you can spot and revoke a misbehaving agent.

Common use cases

  • MCP server for your product
  • Agent-ready public APIs
  • Customer automations and integrations
  • Partner and marketplace agents

Key risks

  • Long-lived API keys pasted into agent configs
  • Prompt-injected agents calling your tools
  • Over-broad scopes across tenants
  • An injected agent approving its own action

Fast path

  • KEEPOAuth with scoped, short-lived tokens
  • KEEPRead-only tools first
  • KEEPAllowlist known clients. No open dynamic registration
  • KEEPPer-client rate limits
  • DEFERAgent behavior analytics until volume grows
C2

AI Features in Your Product

Owner: Product eng + securityControl: High4 to 12 wks

SaaS companies shipping chat, search, summaries or agents to customers. One customer's data must never reach another, and anything a customer uploads is untrusted input.

Implementation guide: products, build vs buy and rollout steps
Your product123456789ACTORCustomer userssigned in, per tenantCONTROLRed team & evalscross-tenant testsSIMPLIFYIDENTITYCustomer identitytenant ID on every callKEEPWORKLOADYour productAI feature + retrievalWORKLOADTenant data / vectorsfiltered by tenant IDKEEPCONTROLTenant AI settingsopt-out, retentionKEEPCONTROLGateway + guardrailsinjection, PII, outputKEEPMODELModel (A3 or A4)no training, ZDR or BAATOOLSActionsvia the toolshed (B3)TELEMETRYPer-tenant AI logsaudit, abuse detectionSIMPLIFY

Data flow

  1. 1A signed-in customer user calls an AI feature. Every request carries the user's tenant ID.
  2. 2Customer identity is checked on every call, never inferred from the prompt.
  3. 3Per-tenant settings check opt-outs and retention before retrieval, so an opted-out customer's data is never fetched or sent.
  4. 4Retrieval filters by tenant before ranking, and your own caches are keyed by tenant, so one customer's documents never reach another's answer.
  5. 5Prompts and retrieved context go through the gateway, where guardrails flag likely injection, PII and unsafe output. Least-privilege actions are the real control.
  6. 6Model calls use a Track A model with no training on customer data, and ZDR or a BAA where needed.
  7. 7Any action the feature takes goes through the toolshed with the customer's own permissions.
  8. 8Logs are kept per tenant for audit and abuse detection.
  9. 9Every release is red-teamed for prompt injection, cross-tenant leaks and unsafe output.

Common use cases

  • In-product chat, search and summaries
  • Customer support bots
  • AI agents inside your app
  • Document and data analysis for customers

Key risks

  • One customer's data in another customer's answer
  • Prompt injection from customer-uploaded content
  • Customer data used for training without consent
  • Shared caches or logs visible across tenants

Fast path

  • KEEPTenant ID enforced on every retrieval and on your own caches
  • KEEPNo training on customer data, in contract and config
  • SIMPLIFYPer-tenant opt-out before per-feature controls
  • DEFEROutput classifiers. Keep regex PII and citation checks from day one
  • KEEPCross-tenant tests in CI before each release

Target state

Every track under one control plane.

T

Enterprise Reference

Owner: CISO + platform engControl: Highest6 to 12 mos

Companies of about 200 or more with dedicated security or platform staff. One control plane for every model call and every agent action, including developers and their coding agents, the AI vendor tenants your people use, and the AI you ship.

Implementation guide: products, build vs buy and rollout steps
Your AI control planeVendor tenants123456789101112ACTORPeople & appsemployees, internal appsACTORDeveloperscoding agents, CI botsWORKLOADAgentsemployee, vendor-run, builtIDENTITYOkta, Entra or Googlepeople, agents, app grantsKEEPCONTROLGateway + guardrailsDLP, budgets, keysKEEPCONTROLDeveloper guardrailssettings, CI gate, pkgsKEEPCONTROLMCP gateway + policytoolshed, OBO, approvalSIMPLIFYCONTROLClassification routerroutes by app and DLPDEFERTELEMETRYSIEM + AI telemetrydetections for AI abuseSIMPLIFYCONTROLData classificationlabels data at restSIMPLIFYCONTROLAI inventorymodels, agents, grantsKEEPCONTROLMDM + EDRdevices, AI apps, local agentsKEEPMODELFrontier APIspublic and internalMODELPrivate cloud modelsBAA-covered (A4)WORKLOADSelf-hosted modelscan't leave boundary (A4)TOOLSInternal APIs & SaaSMODELAI vendor tenantsChatGPT, Copilot, SaaS AIWORKLOADYour product + APIAI features, MCP server

Data flow

  1. 1People, workloads and agents all authenticate through the IdP. Consent and token policy decide which third-party apps and vendor agents get grants, and each vendor gets its own service account or role (B1, B2).
  2. 2All model traffic from your own apps and agents passes one gateway with DLP, guardrails and budgets.
  3. 3The router picks a destination by app tier and DLP findings, and uses data labels where the app supplies them. Unlabeled traffic defaults to the covered route, which costs more.
  4. 4Public and Internal data can go to frontier APIs. Confidential and Regulated data go to BAA-covered models in your cloud. Self-host only what can't leave the boundary.
  5. 5Every agent you run calls tools through the MCP gateway with policy: on-behalf-of tokens where the downstream API supports them, credentials from a secrets manager elsewhere, generated code in a sandbox, human approval for risky actions, and a kill switch that revokes agent tokens.
  6. 6Gateway, router and tool telemetry stream to the SIEM with AI-specific detections.
  7. 7Data classification (Purview, Cyera, Varonis) labels data at rest. Apps pass those labels to the router; no tool feeds it directly.
  8. 8AI inventory and posture tools find models, agents, MCP servers, agent credentials and OAuth grants across cloud, SaaS and endpoints, and feed findings to the SIEM. No single tool sees all of it.
  9. 9Developers and coding agents work under managed settings pushed by MDM, with one-repo tokens and a package firewall. Their model and tool calls use the same gateways, and code ships only through the CI merge gate (B4). Managed settings are strongest for Claude Code; other agents vary.
  10. 10MDM and EDR on every laptop report AI apps, browser extensions, MCP servers and local agents to the AI inventory, and the EDR's AI module watches prompts in the browser.
  11. 11People also use AI inside vendor tenants: ChatGPT, Claude and Copilot enterprise tenants, AI features in your SaaS, and agents built in suites. That traffic never touches your gateway, so the controls are SSO, each tenant's admin settings and connector policy, and audit logs exported into the same SIEM (A2, B1).
  12. 12The AI you ship reuses the same pieces. Product features call models through the gateway, customer agents reach your MCP server through your own OAuth server, and actions go through the toolshed with each customer's tenant ID enforced (C1, C2).

Common use cases

  • Org-wide AI platform
  • Mixed sensitivity across business units
  • Engineering-wide coding agents
  • Central AI governance and reporting

Key risks

  • Complexity slows adoption and drives shadow AI
  • Misclassified data routed to the wrong tier
  • Developer tooling outside the control plane
  • Router becomes a policy bottleneck
  • Vendor tenants and app grants outside the gateway's view

Fast path

  • DEFERRouter. Start with two tiers by app
  • KEEPOne gateway for all traffic from your own apps and agents
  • KEEPSSO, admin settings and audit export on every AI vendor tenant
  • KEEPManaged settings and the merge gate for every coding agent
  • SIMPLIFYStatic tool allowlist before full policy
  • SIMPLIFYTelemetry to bucket first

Reference

Comparison, the fast path guide, other frameworks and vendors by category.

Compare the models

Sorted by control, across all three tracks. The dots are the nine building blocks that recur across the models: build or buy each one once and every runtime reuses it. Timing assumes a team of two to four with executive cover.

IDModelControlStand upGatewayToolshedIdentitySecretsSandboxTelemetryApprovalInventoryEndpoint
A1Direct to ProviderLowHours to 2 wksAI gateway: not usedToolshed / MCP gateway: not usedIdentity (SSO, workload, agent ID, OBO): recommendedSecrets manager: recommendedSandboxed execution: not usedTelemetry to SIEM: recommendedHuman approval gate: not usedAI inventory and posture: not usedEndpoints (MDM + EDR): recommended
A2Workforce AI AppsChat apps · AI inside your SaaSLow to MedDays to 3 mosAI gateway: not usedToolshed / MCP gateway: not usedIdentity (SSO, workload, agent ID, OBO): coreSecrets manager: not usedSandboxed execution: not usedTelemetry to SIEM: recommendedHuman approval gate: not usedAI inventory and posture: coreEndpoints (MDM + EDR): core
B1Employee AI AgentsIn your AI tenant · Outside your tenantLow to MedDays to 8 wksAI gateway: not usedToolshed / MCP gateway: recommendedIdentity (SSO, workload, agent ID, OBO): coreSecrets manager: recommendedSandboxed execution: recommendedTelemetry to SIEM: coreHuman approval gate: provided by the vendorAI inventory and posture: coreEndpoints (MDM + EDR): core
A3Gateway and RouterSelf-hosted · Managed or aggregatorMed to Med-HighDays to 6 wksAI gateway: coreToolshed / MCP gateway: not usedIdentity (SSO, workload, agent ID, OBO): coreSecrets manager: coreSandboxed execution: not usedTelemetry to SIEM: coreHuman approval gate: not usedAI inventory and posture: recommendedEndpoints (MDM + EDR): not used
B2Vendor-Run AgentsMed1 to 6 wksAI gateway: not usedToolshed / MCP gateway: not usedIdentity (SSO, workload, agent ID, OBO): coreSecrets manager: coreSandboxed execution: not usedTelemetry to SIEM: coreHuman approval gate: coreAI inventory and posture: coreEndpoints (MDM + EDR): not used
C1Customer Agents on Your APIMed to High2 to 12 wksAI gateway: not usedToolshed / MCP gateway: recommendedIdentity (SSO, workload, agent ID, OBO): coreSecrets manager: coreSandboxed execution: not usedTelemetry to SIEM: coreHuman approval gate: recommendedAI inventory and posture: recommendedEndpoints (MDM + EDR): not used
B3Agents You BuildLow-code workflow · Custom agentsMed to HighDays to 6 mosAI gateway: coreToolshed / MCP gateway: coreIdentity (SSO, workload, agent ID, OBO): coreSecrets manager: coreSandboxed execution: coreTelemetry to SIEM: coreHuman approval gate: coreAI inventory and posture: coreEndpoints (MDM + EDR): not used
B4Developer AIAttended and CI · Autonomous fleetMed to HighDays to 4 mosAI gateway: coreToolshed / MCP gateway: coreIdentity (SSO, workload, agent ID, OBO): coreSecrets manager: coreSandboxed execution: coreTelemetry to SIEM: coreHuman approval gate: coreAI inventory and posture: coreEndpoints (MDM + EDR): core
C2AI Features in Your ProductHigh4 to 12 wksAI gateway: coreToolshed / MCP gateway: recommendedIdentity (SSO, workload, agent ID, OBO): coreSecrets manager: coreSandboxed execution: recommendedTelemetry to SIEM: coreHuman approval gate: recommendedAI inventory and posture: recommendedEndpoints (MDM + EDR): not used
A4In-Boundary InferenceManaged cloud AI · Self-hosted open weightsHigh to Highest2 wks to 4 mosAI gateway: recommendedToolshed / MCP gateway: not usedIdentity (SSO, workload, agent ID, OBO): coreSecrets manager: recommendedSandboxed execution: not usedTelemetry to SIEM: coreHuman approval gate: not usedAI inventory and posture: recommendedEndpoints (MDM + EDR): not used
TEnterprise ReferenceHighest6 to 12 mosAI gateway: coreToolshed / MCP gateway: coreIdentity (SSO, workload, agent ID, OBO): coreSecrets manager: coreSandboxed execution: coreTelemetry to SIEM: coreHuman approval gate: coreAI inventory and posture: coreEndpoints (MDM + EDR): core
Core to the modelRecommendedProvided by the vendor

Fast path for risk takers

Five places a team can cut corners and still defend the decision. Turn on the overlay to see which components in each diagram are safe to defer, which can be simplified, and which are load bearing.

  1. Use a managed gateway instead of self-hosting.Cloudflare AI Gateway, Prisma AIRS AI Gateway, or provider project keys with spend caps get most of A3 in a day.You lose: one more vendor in the data path.
  2. Defer prompt DLP and guardrails.Rely on zero-data-retention or enterprise terms, plus a written "what data can go in" policy.You lose: catching accidental PII or secrets in prompts.
  3. Use a static tool allowlist before a policy engine.Hardcode which tools each agent can call and start read-only. Add OPA or Cedar past a handful of agents.You lose: fine-grained, context-aware decisions.
  4. Send logs to a bucket, not the SIEM.Immutable storage with retention now, detections later.You lose: real-time alerting. You keep forensics.
  5. Use persistent dev containers instead of ephemeral sandboxes.Only with no prod credentials inside and an egress allowlist.You lose: a clean slate after a compromised session.

Never skip, even for speed

  • No long-lived prod credentials where an agent can read them
  • No long-lived personal access tokens to source code or sensitive SaaS
  • Human review before code ships to production or any irreversible action
  • Scoped, short-lived tokens for tool and repo access
  • Spend limits on every model project or workspace
  • Some form of logging, even if it is just a bucket
KEEPload bearing SIMPLIFYlighter option is fine DEFERadd later

How these models map to other frameworks

If you already work from the AWS scoping matrices or the OWASP lists, here's where each model sits. The AWS Generative AI Security Scoping Matrix runs from scope 1 (consumer apps) to scope 5 (models you train yourself), which none of these models cover. The AWS Agentic AI Security Scoping Matrix runs from no agency to full agency, which none of these models recommend. The OWASP column lists the top risks from the LLM Top 10 (2026) and the Agentic Top 10 that each model's controls address.

IDModelAWS GenAI scopeAWS agentic scopeMain OWASP risks
A1Direct to Provider3No agencyLLM02 LLM06
A2Workforce AI Apps1 and 2No agency to supervised (AI browsers, suite agents)LLM01 LLM02 ASI02
A3Gateway and Router3No agencyLLM01 LLM02 LLM04 LLM06
A4In-Boundary Inference3 and 4No agencyLLM02 LLM04 LLM05
B1Employee AI Agents1 and 2Prescribed (user approves) to supervised; on unmanaged devices only consent and token policy applyASI01 ASI03 ASI04 ASI06 ASI09
B2Vendor-Run Agents2Prescribed (analyst approves actions) to supervisedASI01 ASI03 ASI04
B3Agents You Build3Prescribed to supervisedASI01 ASI02 ASI03
B4Developer AI2 and 3Prescribed (attended) to supervised (fleet)ASI01 ASI04 ASI05
C1Customer Agents on Your API3Prescribed (out-of-band confirm)ASI02 ASI03 ASI09
C2AI Features in Your Product3 and 4No agency to prescribedLLM01 LLM02 LLM09
TEnterprise Reference1 to 4Prescribed to supervisedLLM01 LLM02 ASI01 ASI02 ASI03

ASI01 Agent Goal HijackASI02 Tool Misuse and ExploitationASI03 Identity and Privilege AbuseASI04 Agentic Supply Chain VulnerabilitiesASI05 Unexpected Code ExecutionASI06 Memory and Context PoisoningASI09 Human-Agent Trust ExploitationLLM01 Prompt InjectionLLM02 Sensitive Information DisclosureLLM04 Supply ChainLLM05 Data and Model PoisoningLLM06 Unbounded ConsumptionLLM09 Vector and Embedding Weaknesses

Above all eleven sits the governance layer: the NIST AI RMF for structure, ISO 42001 for certification, and MITRE ATLAS for red teaming. Our AI governance cheatsheet covers those, plus the AI laws and their dates.

Reference AI security vendors by category 26 categories of products, from AI gateways and MCP gateways to EDR AI modules, mapped to the architectures that use them. See the vendors

Find your target AI architecture in one call

Bring the AI tools your teams use today and the data they touch. In a 30-minute call a CISO maps you to these models and names the controls to add first. No sales pitch.

Talk to a CISO