Frontier AI security protects advanced AI systems, as well as the infrastructure that runs them, the data they process, and the actions they can take through connected tools. It governs model access, weights, prompts, retrieval, agents, permissions, evaluations, monitoring, and incident response so frontier capabilities can operate without exposing enterprise systems, users, or sensitive data.
Frontier AI security protects advanced AI systems as operational infrastructure. The scope covers the model, the data that grounds it, the tools it can call, the identities it can use, and the decisions it can influence.
Earlier AI risk programs focused on generated content — hallucinations, toxicity, bias, inappropriate disclosure. Frontier AI demands strict discipline because model output increasingly triggers operational action. A model connected to enterprise systems can open a ticket, query a database, summarize a confidential file, call an API, modify a cloud resource, or guide a human through a high-risk change. OWASP's LLM Top 10 reflects that shift — prompt injection and excessive agency now rank as primary risks precisely because frontier systems can act.
Risk moves through the full execution path — prompts, embeddings, retrieval stores, API calls, SaaS connectors, code interpreters, browser sessions, memory, logs, and human approvals. The model sits at the center, but exposure lives at every connection point. NIST's Generative AI Profile frames generative AI risk as a cross-sector governance issue requiring management across the AI lifecycle, and security programs need to match that scope.
Boards and CISOs need a governance model built for that operating reality. AI risk surfaces as a cyber incident, privacy failure, supply chain compromise, insider event, cloud misconfiguration, or regulatory disclosure problem — often without signaling which domain owns it. A policy document won't control an AI agent holding production credentials. A risk committee won't see exposure without logs. A SOC won't investigate AI misuse when prompts, retrieval events, tool calls, and agent actions sit outside its detection fabric.
Frontier AI security belongs inside the enterprise security architecture, drawing on software security discipline, identity governance rigor, cloud security visibility, SOC response capability, privacy engineering data controls, and executive risk accountability.
Frontier models operate as composed systems, and security controls must span the model, context pipeline, retrieval layer, tool interfaces, identity paths, orchestration logic, and runtime telemetry.
A frontier AI system typically combines a foundation model with post-training layers, safety classifiers, retrieval systems, orchestration logic, and tool interfaces. Post-training shapes behavior through instruction tuning, preference optimization, reinforcement learning, adversarial testing, and policy training. Reasoning models add a compounding control problem. They allocate compute to planning and problem-solving before responding, and current reasoning systems combine that planning capability with tool access, including web browsing, code execution, file analysis, and memory. Security teams should treat the full toolchain as attack surface.
Model routing adds further complexity. A single user request may pass through intent classification, safety review, retrieval, planning, model selection, tool execution, output inspection, and policy enforcement before the user sees a response. A weakness at any step can compromise the whole workflow, which means each step needs logging, ownership, change control, and failure-mode testing.
Context compounds the exposure. Frontier systems assemble working context from system instructions, user prompts, prior conversation, retrieved documents, uploaded files, tool results, memory entries, code outputs, and policy constraints — all inside a single context window that may include attacker-controlled material. A signed system instruction and a retrieved web page don't carry equal trust, but the model receives both. A malicious document can embed hidden instructions. A retrieved policy can be stale or poisoned. A tool result can inject commands back into the model's next reasoning step.
Memory requires separate governance. Persistent memory improves continuity but can preserve sensitive facts, business logic, credentials, regulated data, or adversarial instructions across sessions. Controls need retention limits, user visibility, administrative policy, audit logs, and deletion paths.
Tool use converts the model from a responder into an operational actor. Current frontier systems combine reasoning with tool calls during problem-solving, meaning that the model may observe, decide, act, and revise across multiple steps before reaching a stopping condition.
Agents extend that pattern further, decomposing goals and choosing tools, and then inspecting results and autonomously adjusting plans. The security boundary must follow the agent's effective authority:
Actions need to be classified by consequence. Read-only analysis, draft generation, ticket creation, code changes, cloud modifications, and production operations each carry different risk and require different approval paths.
Related Article: How the Latest Frontier AI Models Are Driving the Need for Real-Time Cloud Security
Frontier AI security starts with architecture because model behavior emerges from the full system. A safe model can still produce unsafe outcomes when it receives poisoned context, retrieves overpermissive data, calls an exposed tool, uses broad credentials, or acts inside a weak approval workflow. Critically, failure tends to emerge between components rather than solely inside the model, which means base-model testing can't surface system-level risk.
A model may pass a safety evaluation and still leak data because the retrieval layer ignores document permissions. It may refuse harmful instructions and still trigger an unsafe action because a tool grants excessive authority. It may generate an accurate answer and still violate policy because the orchestration layer routes regulated data to the wrong endpoint. Understanding this, attackers bypass the model and target the seams between components.
The execution path is the right organizing principle because it makes every other control decision coherent. Security teams need to know which user or agent invoked the system, what context entered the model, which data sources retrieval accessed, which tools became available, which identity authorized action, and what changed downstream.
Control points belong where authority changes. The critical boundaries are user to model, model to retrieval, model to tool, tool to enterprise system, and output to downstream workflow. Each represents a trust transition, a point where the AI system either gains access to something new or produces output that affects something outside itself. High-risk boundaries warrant stronger enforcement — entitlement-aware retrieval, scoped agent credentials, approval gates for consequential actions, isolated execution environments, and telemetry routed to the SOC.
The architectural goal is preventing the AI system from accumulating more access, context, or action authority than the specific workflow requires.
Frontier AI governed in a silo will be ungoverned in practice. The architecture must connect IAM, data security, application security, cloud security, SaaS security, vendor risk, and incident response because an incomplete connection is where real exposure hides. A team that approves a model deployment while missing the vector store it queries has approved half a system. A team that monitors the endpoint while missing the tool call has half the evidence it needs.
A useful threat model classifies exposure by the role the AI system plays. The same model can be an asset an attacker targets, a tool an attacker weaponizes, an actor operating inside enterprise workflows, a processor of sensitive data, and a supply chain dependency. Each role requires different controls, evidence, and response paths.
A frontier model becomes a target when an attacker seeks to steal, alter, clone, or misuse it. Weight theft is the highest-impact scenario. Stolen weights let an adversary replicate capability, bypass provider controls, fine-tune for misuse, or probe safety mechanisms outside monitored infrastructure.
Model extraction offers a different path. An attacker repeatedly queries the model and uses the outputs to train a substitute system, exposing commercial capability and revealing decision boundaries without ever touching the weights directly.
Unauthorized access broadens the surface further. A compromised account, leaked API key, overpermissive service token, or weak tenant boundary can expose frontier capabilities to users who shouldn't have them. Controls should cover identity, infrastructure, and provenance — privileged access management, hardened training and inference environments, secrets protection, strong tenant isolation, signed model artifacts, version control, tamper-evident logs, anomaly detection, and provider notification requirements.
A frontier model becomes a tool when an attacker uses it to accelerate offensive work — phishing, reconnaissance, exploit generation, vulnerability discovery, malware development, credential harvesting, and social engineering at scale. Recent evaluations make the trajectory concrete. The UK AI Security Institute reported that Claude Mythos Preview showed significant improvement on multistep cyberattack simulations, and GPT-5.5 became the second model to complete one of AISI's multistep simulations end to end. Anthropic has disclosed that nonexperts used Mythos Preview to find and exploit sophisticated vulnerabilities, including remote code execution flaws.
Full autonomy isn't required for meaningful adversary uplift. A model can translate a vague target into an actionable plan, covering everything from identifying exposed services and drafting lure variants to adapting public proof-of-concept code and troubleshooting failures along the way. Defensive planning should assume faster adversary iteration and respond by tightening exposure management. Teams need next-generation identity hygiene and exploitability-aware patching, in addition to detection engineering for AI-assisted tradecraft and incident playbooks built for automated reconnaissance and high-volume social engineering.
A frontier model becomes an actor when it can take steps through delegated access, as in querying SaaS systems, modifying cloud resources, writing and submitting code, updating records, sending messages, or triggering enterprise workflows. Agency converts model error into operational consequence. A bad tool call, for instance, can change production state, expose data, or disable a control. It can create a persistence path that looks like legitimate activity.
Governing model-as-actor risk requires tracking effective authority across seven dimensions:
A frontier model becomes a data processor when it ingests, transforms, stores, retrieves, or generates information. Often without deliberate disclosure by the user, sensitive data enters AI workflows through prompts, uploaded files, logs, source code, ticket comments, call transcripts, retrieval indexes, training data, memory, and generated outputs.
Retrieval-augmented generation (RAG) creates a specific risk pattern. The system retrieves documents on the user's behalf and blends them into a response, meaning weak retrieval design can surface material the user couldn't access directly, expose confidential facts through summaries, or inject stale or poisoned content. Embeddings and vector stores compound the problem because they can preserve semantic traces of sensitive content even after the source document is restricted or deleted.
Controls must cover the full data path — entitlement-aware retrieval, prompt and output logging, retention limits, encryption, tenant isolation, DLP for AI channels, secrets detection, memory governance, and embedding-store access control.
A frontier model becomes a supply chain dependency when enterprise workflows rely on external models, fine-tunes, adapters, datasets, plugins, orchestration frameworks, vector databases, evaluation suites, or agent runtimes. It’s easy to imagine, then, that a compromised dataset, malicious adapter, poisoned retrieval corpus, or misconfigured model gateway can affect every downstream workflow that trusts it.
Version drift adds a quieter risk. A model that passed evaluation in March may behave differently after an April update, and a connector that shipped with read-only access may gain write capability through a routine product release.
AI security teams need provenance and change control across model versions, system prompts, policy configurations, retrieved sources, tool manifests, plugin permissions, evaluation results, and approval records. Vendor contracts should address training use, retention, audit logs, model-change notification, breach notification, subprocessors, exportability, and incident cooperation.
A disciplined threat model makes frontier AI security measurable — protect the model as an asset, constrain it as a tool, govern it as an actor, secure it as a data processor, and validate it as a supply chain dependency.
Related Article: Frontier AI and the Future of Defense — Your Top Questions Answered
Frontier AI security becomes difficult when model capability, enterprise integration, and governance maturity move at different speeds. The threat model identifies what must be protected. The harder problem is building controls that hold across probabilistic reasoning, sensitive data, delegated access, third-party systems, and live business workflows — all simultaneously.
Frontier AI rarely enters the enterprise through a single sanctioned platform. It arrives through SaaS copilots, developer assistants, embedded product features, model APIs, agent builders, browser extensions, and shadow workflows built by employees under pressure to move faster than procurement allows. By the time security teams discover a workflow, it may already hold production credentials, process regulated data, and sit outside every logging requirement the organization has.
Prompt injection exploits a structural property of frontier models — the inability to reliably distinguish trusted instruction from untrusted content. An attacker embeds hostile instructions inside a web page, document, email, ticket, image, or retrieved knowledge object and waits for the model to process it. No active session is required. The attack travels with the content.
Instruction conflict compounds the exposure. During a single task, a frontier system may receive system instructions, developer instructions, user prompts, retrieved documents, memory entries, tool outputs, and external content — all inside one context window. The model resolves competing signals without inherent awareness of which sources an attacker controls.
Excessive agency is what transforms model error into business impact. A model that only generates text can mislead a user. A model with tool access can modify a record, send a message, submit code, disable a control, open a firewall rule, approve a transaction, or trigger a downstream workflow — and do so at machine speed, across multiple systems.
OWASP identifies excessive autonomy, excessive functionality, and excessive permissions as the common root causes. Each one expands the blast radius of a model failure, which makes the scope of delegated authority the central design question for every agentic workflow.
Frontier AI creates leakage paths at every stage of the workflow — prompts, uploads, chat history, retrieved documents, embeddings, vector stores, tool outputs, model memory, fine-tuning data, evaluation sets, telemetry logs, and generated responses. Sensitive data enters AI workflows because a user pastes it, a connector retrieves it, a file parser extracts it, a memory feature stores it, or a retrieval system returns content the user was never entitled to see.
The most underappreciated exposure pattern is treating retrieval as search rather than authorization. A vector index can surface material the requesting user couldn't open directly. A model can distill confidential information into a summary that moves it into a lower-trust channel. A telemetry log can retain regulated data long after the originating system would have enforced a retention limit. The exposure in each case isn’t a breach. It’s the system working as designed, with insufficient controls on what it was allowed to reach.
An evaluation reveals weaknesses, which is not equal to certifying durable safety. A benchmark measures a bounded task under defined conditions. A red-team exercise explores selected attack paths at a point in time. Neither evaluation accounts for what happens when providers update models, users alter workflows, connectors gain permissions, and attackers adapt.
Evaluation must follow the system into production, contrary to sitting in a launch checklist that no one reviews again.
Frontier models generate fluent rationales without exposing the internal causal path behind an output. A model-generated explanation may be coherent and wrong about why the model acted. It may omit the retrieved document that drove a decision, the tool call that changed state, or the policy check that should have blocked an action.
Without explainability and system-level traceability, generated outputs can circulate as evidence while the actual decision path remains invisible.
The enterprise consequence of advancing frontier model capability is exposure compression. Vulnerability discovery, exploit reasoning, reconnaissance, scripting, and attack-path planning all accelerate as models improve. Weak patch pipelines, stale assets, exposed management planes, permissive identities, and inadequate logging were always liabilities. Frontier AI raises the speed at which adversaries can find them, chain them, and operationalize them.
Related Article: Frontier AI and the Future of Defense — Your Top Questions Answered
Frontier AI security controls must make model behavior, data access, tool use, and human approval governable under real operating conditions. The framework combines prevention, detection, response, and governance, allowing teams to reduce exposure before deployment, surface misuse in production, and contain failure when controls break.
Preventive controls limit what frontier AI systems can access, ingest, retrieve, generate, and execute before the model receives context or any tool acts on its output.
Access control starts from a single principle — no AI identity should hold more access than its specific workflow requires. Users, agents, service accounts, plugins, and connectors all need scoped credentials. Auditable and revocable credentials. Agentic systems make this challenging because they can acquire and exercise access faster than any human reviewer can track.
Data minimization keeps sensitive material out of model context by default. Regulated data, credentials, proprietary code, and customer records need redaction or tokenization before reaching prompts, retrieval calls, or model memory unless policy explicitly permits exposure. The entry points are numerous enough that passive accumulation is the norm without deliberate controls to prevent it.
Prompt hardening enforces instruction hierarchy so that system instructions, user input, retrieved documents, and tool results are treated as distinct trust tiers. AI gateways and secure orchestration layers can enforce approved system prompts, block unsafe prompt patterns, and prevent untrusted content from overriding privileged instructions.
Retrieval permissions must be enforced at query time. A retrieval system that checks permissions at index time but not at query time will surface material users were never authorized to see. High-risk workflows should restrict retrieval to approved, signed corpora so external content can’t reach the model through the retrieval path.
Tool permission scoping gives each tool a manifest defining allowed actions, required approvals, and rollback behavior. Code interpreters, browsers, and agent runtimes should run inside constrained environments with no production access unless policy grants it for a specific task. Sandboxing and egress filtering keep a compromised tool call from becoming a production incident.
Policy-as-code makes AI rules enforceable rather than advisory. Teams should codify allowed models, approved data classes, permitted tools, action thresholds, approval requirements, and logging mandates inside model gateways, orchestration layers, CI/CD pipelines, and agent runtimes. A policy that lives only in a document won’t stop an agent with production credentials.
Detective controls convert AI activity into security telemetry cloud and SOC teams can act on. Visibility must span prompts, completions, retrieved sources, embedding queries, model refusals, tool calls, policy overrides, memory writes, approval events, blocked actions, and agent plans.
AI activity logs should feed SIEM, SOAR, XDR, CNAPP, CDR, UEBA, and data security platforms. Each log record needs user identity, agent identity, model version, system prompt version, retrieved sources, tool-call arguments, policy decisions, approvals, output disposition, and downstream changes.
Because logs that capture AI activity inherit the data classification of the content they describe, sensitive log fields require encryption, retention limits, role-based access, and redaction.
Anomaly detection should correlate AI activity against identity, cloud, endpoint, SaaS, code repository, API, and data movement telemetry. Patterns worth detecting include unusual prompt volume, abnormal retrieval breadth, repeated access to sensitive indexes, suspicious tool sequences, unexpected memory writes, large output exports, and agent actions that fall outside approved task boundaries.
Prompt injection detection must cover indirect inputs — web pages, documents, tickets, emails, code comments, tool results, and retrieved content— in addition to user prompts. AI gateways and prompt inspection tooling should flag hidden instructions, attempts to override system prompts, data-exfiltration language, and requests to reveal policies or credentials.
Tool-call correlation connects model actions to downstream system events. Whether an AI-generated action created a pull request, changed a cloud policy, queried a sensitive database, or modified a customer record, it should be visible through API logs, SaaS audit trails, cloud audit logs, CI/CD records, and XDR. As well, it should link back to the originating prompt and agent identity.
Model behavior drift monitoring tracks refusal rates, unsafe output rates, hallucination patterns, retrieval accuracy, tool-call frequency, and jailbreak susceptibility after model or orchestration updates. A provider update that improves general capability may simultaneously weaken refusal behavior or change how the system handles ambiguous instructions. Regression signals should feed both release governance and SOC visibility.
Responsive controls contain AI incidents quickly and preserve evidence for investigation. The response plan should assume failure can originate anywhere in the execution path — model, retrieval layer, tool chain, identity path, provider environment, or human approval process.
Agent shutdown must be enforceable without waiting for engineering. Security teams need the ability to pause an agent, disable a tool, revoke a model route, stop a workflow, or force read-only mode.
Credential revocation must cover API keys, OAuth grants, service principals, cloud roles, SaaS tokens, plugin credentials, and agent-issued temporary credentials. Revocation should automatically trigger review of recent tool calls, data access, exports, code commits, ticket changes, and cloud modifications tied to the compromised identity. Because the agent has already acted by the time a credential is flagged (usually), this is key.
Output quarantine holds generated content when systems detect prompt injection, unsafe retrieval, data exposure, or tool misuse. Generated code, customer messages, policy documents, incident summaries, and configuration changes should pass through secure release workflows and review gates before reaching downstream systems or external recipients.
Retrieval rollback requires the ability to remove poisoned or overexposed documents from indexes, rebuild embeddings, invalidate cached retrieval results, restore prior corpus versions, and confirm that query-time authorization now enforces the intended boundary. Remediating a retrieval compromise without validating the authorization fix leaves the same exposure path open.
Incident escalation should route AI events through SOAR, case management, privacy workflows, legal workflows, engineering ticketing, and vendor-risk processes.
Provider notification belongs in the same playbook — model behavior anomalies, platform compromises, data retention questions, and logging access may all require vendor action or contractual evidence that the organization can't obtain after the fact.
Governance controls make frontier AI security repeatable by tying ownership, approvals, testing, audit trails, and vendor obligations to each AI system's risk tier.
Model cards and system cards serve as the control record for each deployment, documenting intended use, prohibited use, model and provider dependencies, evaluation results, data boundaries, and residual risk ownership. Risk assessments should examine the full AI workflow:
Approval controls should scale with risk. Low-risk internal assistants may need standard policy review. Customer-facing systems, regulated workflows, code-writing agents, security automation, financial actions, and production-change agents require security architecture review, as well as legal review, deeper testing, and executive risk acceptance where material exposure remains.
NIST AI 600-1 provides a generative-AI-specific companion to the AI Risk Management Framework, and MITRE ATLAS organizes adversarial AI techniques into testable scenarios. Both are useful anchors for building evaluation requirements that reflect real-world attack patterns rather than synthetic benchmarks.
Audit trails must connect AI gateways, model observability, SIEM, SaaS audit logs, cloud logs, source-code systems, ticketing platforms, approval workflows, and GRC records into a defensible chain.
A complete record shows who invoked the AI system, which model ran, which instructions applied, which sources were retrieved, which tools executed, which approvals occurred, which outputs were produced, and which downstream actions followed.
Vendor commitments require explicit contractual language covering training use, prompt and output retention, tenant isolation, subprocessors, regional processing, model-change notifications, logging access, breach notification, incident cooperation, red-team evidence, termination support, and data exportability.
Ambiguous terms become operational problems during incidents and investigations.
Board reporting should show whether frontier AI use is visible, governed, and containable. Useful metrics include AI asset coverage, high-risk systems approved, sensitive data exposure events, prompt injection attempts, agent actions by consequence class, blocked tool calls, evaluation failures, unresolved vendor risks, incident readiness, and time to revoke compromised agent credentials.
Frontier AI testing must run before deployment and continue after release. A model can pass every predeployment benchmark and still fail inside a live enterprise workflow because production adds users, sensitive data, retrieval systems, tools, agents, and approvals, as well as adversarial pressure that synthetic tests don't quite anticipate.
Predeployment evaluation should cover the model, the surrounding application, and the connected workflow together.
Capability testing establishes what the system does under approved conditions — reasoning, tool selection, retrieval accuracy, refusal behavior — across scenarios that reflect production data and actual user roles.
Jailbreak and prompt injection testing must pressure indirect inputs as much as direct ones. Documents, web pages, tickets, emails, and retrieved content are higher-risk injection surfaces than direct user prompts because they reach the model through channels users don't control and may not monitor.
Data leakage testing verifies the system doesn't expose secrets, regulated data, proprietary code, customer records, or content available through another user's permissions. Testing extends across prompts, uploads, retrieved sources, completions, logs, embeddings, memory, and tool outputs.
Cyber misuse evaluation assesses whether the system provides meaningful uplift for phishing, exploit generation, vulnerability discovery, or credential theft. MITRE ATLAS organizes adversarial AI techniques into scenarios grounded in real attack patterns rather than hypotheticals.
One-time approval doesn't carry assurance for systems that change continuously. Model updates, prompt revisions, retrieval changes, and connector updates can all alter behavior in ways predeployment testing never anticipated. A model update that improves general capability may simultaneously weaken refusal behavior or change how the system handles ambiguous instructions.
Regression suites should rerun after every material change, covering prior jailbreaks, prompt injection payloads, leakage tests, retrieval poisoning tests, and known production incidents. Failed tests are the most valuable artifacts in the suite, as they define confirmed exposure and anchor future regression coverage.
Production feedback loops close the gap between evaluation and reality by routing SOC findings, DLP events, red-team results, user reports, and postincident reviews back into the test suite. The strongest regression signal is a mismatch between what the workflow was designed to do and what the AI system did under pressure.
AI red teaming should attack the full system — prompts, retrieval indexes, memory, tools, agents, connectors, approval processes, downstream workflows, and the human trust paths connecting them. Scoping red team work to the model alone misses where most real attacks land.
A mature red team attempts the spectrum of adversarial activities, from manipulating context, extracting data, and poisoning retrieval, to inducing unsafe tool calls, escaping sandboxes, and chaining actions beyond approved authority. OWASP's LLM Top 10 provides a practical framework covering prompt injection, insecure output handling, supply chain vulnerabilities, and tool and permission abuse.
Human approval processes deserve dedicated testing. A model can draft a confident justification for a risky action, mislabel a destructive change as routine, or omit the evidence a reviewer needs to push back. Red teams should verify that approvers receive source lineage, tool history, risk classification, and rollback implications (vs a model-generated summary presenting the action favorably).
Assurance depends on reproducible evidence. Useful records capture which model ran, which system prompt applied, which sources were retrieved, which tools executed, which approvals occurred, and which downstream actions followed. Source-linked outputs let reviewers distinguish evidence from inference. A generated summary earns evidentiary weight only when it identifies the documents, logs, and telemetry behind each claim.
Evaluation records should capture test objectives, model version, observed failures, mitigations applied, residual risk, and regression coverage. Residual risk requires explicit ownership. Some systems launch with accepted limitations or narrower access than originally designed, and assurance means leaders know who accepted that risk and which signal would trigger reassessment.
Frontier AI security needs a standing operating model with defined ownership, risk tiering, decision rights, policy enforcement, exception handling, and board reporting.
Risk tiering gives the organization a consistent basis for deciding which systems need deeper review rather than making those decisions under deployment pressure. ISO/IEC 42001 provides a management-system approach that makes tiering repeatable across business units rather than discretionary by project.
Decision rights define what AI may recommend, draft, execute automatically, or route for human approval. Without them, frontier AI embeds into workflows faster than risk owners can distinguish assistance from authority.
Agentic workflows need named approvers by action class — cloud changes to the service owner, privileged identity changes to the IAM owner, customer-impacting communications to legal or support leadership. The operating model should also define who overrides a block and who accepts residual risk, as those decisions happen under pressure and ambiguity claims them if ownership isn't pre-assigned.
Frontier AI policy should define acceptable use, prohibited data types, approved providers, agent and tool permissions, retrieval boundaries, and evaluation requirements. This should include when enterprise AI gateways are mandatory and which data classes can’t enter external models.
Exception management requires discipline because deployment pressure will always push against controls. Every exception needs a named owner, expiration date, compensating controls, and monitoring requirement. Exceptions without expiration dates become shadow policy and accumulate until an incident makes them visible.
High-risk exceptions — agents with write access, external model use with sensitive data, provider terms that limit auditability — require security, privacy, legal, and business review before approval.
Frontier AI enters the enterprise through suppliers as often as it enters through internal engineering. Model providers, embedded SaaS AI features, agent builders, orchestration frameworks, and AI-enabled security tools all process enterprise data under terms and architectures the security team didn't design and may not fully understand.
Standard security questionnaires don't capture enough AI-specific risk. Due diligence needs evidence on the questions that matter most operationally:
Training use should be prohibited by default for enterprise data, with any exception requiring written approval for a specific purpose. Retention terms cut in both directions — short retention weakens investigations while excessive retention expands breach impact. Model updates create change risk that most vendor relationships don't adequately address. Providers should commit to change notifications for material behavior shifts, version pinning where feasible, and customer-controlled rollout for high-risk workflows.
Embedded AI creates the hardest inventory problem because it arrives inside products the enterprise already trusts, often without a new procurement event. A SaaS vendor that adds autonomous ticket routing, code assistance, or agentic workflow execution may change the product's data exposure, permission model, and regulatory profile — without triggering the review that a new tool would.
Developer platforms and security products warrant particular scrutiny. AI coding tools can access proprietary code, generate vulnerable dependencies, and interact with CI/CD systems. AI features in security products may process logs, detections, incident evidence, and vulnerability details — sensitive material that warrants the same review applied to the security product itself.
Agent builders connecting to email, source-code repositories, cloud consoles, or data warehouses deserve the highest review tier, with explicit evaluation of default permissions, credential handling, approval gates, and emergency disablement.
AI contracts need explicit language where ambiguity creates operational exposure. Spell out data ownership, training use, prompt and output retention, breach notification triggers, regulator support, model-change notification, audit rights, and exit terms.
Breach notification should cover AI-specific events (i.e., unauthorized access to prompts, outputs, retrieval indexes, embeddings), in addition to traditional data breach triggers. Exit rights should ensure the organization can retrieve logs, evaluation records, configuration files, and audit history, and that termination includes deletion certificates from subprocessors.
Dependence on a small number of model providers, vector databases, and orchestration frameworks creates risk that compounds quietly. A single provider change can affect pricing, availability, safety behavior, logging access, and contractual terms across many workflows simultaneously.
Resilience requires knowing the dependency map before a disruption forces the question. Do you know which business processes depend on which providers and which retrieval systems hold sensitive data? Are you aware of which workflows have no fallback? Critical AI systems should define in advance whether the organization can switch providers, revert to manual processing, and satisfy regulatory obligations during provider disruption.
Vendors that control the model, the retrieval layer, and the embedded workflow surface can limit telemetry access and policy enforcement in ways that only become apparent under pressure. Think about that. It makes a strong argument for architectural choices that preserve customer control over data boundaries regardless of which provider sits behind them.
Frontier AI metrics should tell you whether the organization can find its AI systems, control what they access, constrain what they do, and contain failure when it happens.
The most important distinction is between raw AI adoption and governed AI adoption. A rising inventory count may signal innovation, expanding exposure, or both. Coverage metrics — the percentage of AI systems that are risk-tiered, owner-assigned, monitored, and carrying approved data boundaries — show whether security has kept pace with the spread of models, agents, and embedded features across the enterprise.
Retrieval authorization deserves its own measurement because it fails quietly. How often retrieval systems return content outside the requester's entitlement, and how many vector indexes enforce permissions at query time rather than only at index time, are more operationally meaningful than aggregate data loss prevention counts.
For agentic systems, approval metrics should distinguish speed from control quality. A fast approval path is a liability if reviewers lack source lineage, tool-call history, and rollback context. The right metric is whether approvers received the evidence needed to make a defensible decision.
On the response side, speed matters less than evidence preservation. An incident that closes quickly but leaves no record of which prompts ran, which tools executed, and which downstream systems changed makes recurrence more likely. After any prompt injection attempt, data leakage event, or agent misuse case, the closing validation should answer whether the same failure path remains open through another model, connector, or workflow.
