ARMOR in Practice: A Security Architecture for Foundation Models

Who this guide is for

This guide is written for security leaders and practitioners responsible for making enterprise AI safe: security architects and engineers building the controls, security and platform leaders deciding where to invest, identity and SOC teams who operate and monitor the controls and the application and developer teams adopting AI assistants day to day. It assumes familiarity with enterprise security building blocks, identity, endpoint, network, cloud and SIEM, and translates them into the unique risks and control requirements of foundation-model usage. It is vendor-aware but vendor-neutral: it recommends categories of control and where they belong; specific products are intentionally not named here, but WWT can recommend and validate solutions suited to a given environment. 

Executive summary

Enterprises are adopting foundation models faster than most security programs were designed to govern, first through everyday tools and unsanctioned paths such as browsers, personal accounts, SaaS and APIs, and increasingly through agentic assistants that take action rather than just generate text. The main risk is not one exotic attack, but widespread unauditable usage spread across surfaces that traditional controls do not see. Securing that usage means knowing which user or agent initiated each interaction, what data it carried, which model received it, how the interaction was processed, whether policy was enforced and being able to prove it afterward.

On January 6, 2026, World Wide Technology (WWT) announced its AI Readiness Model for Operational Resilience (ARMOR), a vendor-agnostic solution, delivered by WWT, leveraging a jointly developed framework with NVIDIA. ARMOR is among the first vendor-agnostic, end-to-end AI security frameworks designed to empower organizations to accelerate AI adoption confidently while helping maintain robust security, compliance and operational resilience. Its latest version (ARMOR v2) organizes the work into seven domains, with Identity Security as the newest addition and Resilience as the operational-resilience outcome across them.

This guide presents a reference architecture that does exactly that. It enforces at four planes: the endpoint and browser, network, cloud and the model-layer controls, and binds every interaction to an identity, for humans and for the non-human identities that now vastly outnumber them. It treats the chat, coding-assistant and agentic-desktop surfaces as one estate, treating chat, coding assistants and agentic desktop tools as part of one governed environment with shared enforcement; it keeps the endpoint light by minimizing overlapping tooling by reducing redundant endpoint agents where possible; it inspects model traffic and routes sensitive work to models inside the approved enterprise models and environments; and it adds the agent-specific controls, guardrails, sandboxing, circuit breakers and just-in-time identity using temporary, scoped identity for specific agent actions that autonomy demands.

Anthropic's Claude (Chat, Code and Cowork) is the worked example, but every control is model agnostic. The guide also maps where commodity platforms overlap (so teams consolidate) and where genuine gaps require a specialist, and it positions the whole design inside a broader AI-security program so point-in-time choices become a measurable, maturing capability. 

Primer: The whole guide in one shift 

The summary above reduces to a single core idea: Generative AI governs the content of an output; agentic AI takes an action with real identity, permissions and consequences. So, the security question moves from "is this output acceptable?" to "is this action's intent aligned, and can I prove who did it?" Everything that follows is built to answer the second. 

Business outcomes

• The point of this architecture is not control for its own sake; it is to let the organization adopt AI aggressively while staying defensible. Done well, it delivers five outcomes:
• Faster, safer AI adoption, because guardrails and clear ownership let teams say "yes" to AI instead of blocking it.
• Reduced data-leakage and IP risk, because sensitive data is discovered, classified and kept out of prompts and egress.
• Lower operational cost and toil, because consolidating overlapping endpoint agents cuts licenses, consoles and performance drag.
• Demonstrable compliance, because every interaction is logged and attributable for audit and regulation.
• Resilience to AI-specific failure, because containment and graduated response limit the blast radius when an agent is manipulated.

These are the terms in which the program should be measured and funded. 

Key terms

Plain-English definitions for the core terms used throughout this guide. A full list of acronyms and abbreviations appears in Appendix B. 

What we are securing

Every foundation-model surface shares one control problem: an identity (human or agent) sends a prompt, data flows to a model and the model may return content or take an action. In the worked example, the chat assistant is mostly browser-mediated knowledge work, where the risk is sensitive data entering prompts; the coding assistant raises software-supply-chain and excessive-agency risk through generated code and connected tools; and the agentic desktop assistant acts across files and applications, so least privilege, session isolation, access hygiene and attribution matter most. The architecture treats them as one governed environment with shared enforcement rather than three bolt-on point solutions, and two design constraints run throughout: reduce the number of agents on endpoints, and map explicitly where product capabilities overlap, so teams consolidate deliberately, and where genuine gaps remain for a specialist to fill.

These surfaces recur as four common deployments. Each pulls in the same controls at a different intensity, rising with autonomy: 

Ordered by increasing autonomy. The threat model and capability map that follows expands each of these. 

The reference architecture

The architecture enforces at four planes and binds every interaction to an identity:  

• Endpoints (Windows and Linux) run the AI surfaces behind a single consolidated agent and a governed enterprise browser.
• Network traffic passes a Secure Service Edge that discovers shadow AI, applies zero-trust access and inspects AI traffic inline.
• A cloud control plane provides identity, data security, posture and the SIEM.
• External egress reaches the model provider's API, other foundation models or enterprise-hosted local models only under inspection.

The provider's own native controls, single sign-on, managed policy and a compliance/audit feed, layer on top, and an identity spine governs humans and non-human identities with just-in-time access. 

Threat model

The controls in this guide answer a concrete set of threats. The matrix below summarises the most material ones for foundation-model usage, the primary control that addresses each, a detection signal that shows it is working or failing and the residual risk that remains after the control is in place. It is a starting point for a deployment-specific threat model, not an exhaustive catalogue.

Table 1. Threat model for foundation-model usage, threat, vector, primary control, detection signal and residual risk. A starting point for a deployment-specific assessment. 

Provider-native controls and one gap to instrument

Any external model provider should be governed both by the enterprise's own planes and by the controls the provider exposes. In the worked example these are concrete:  

• Single sign-on via SAML 2.0 or OIDC ties model identities to the corporate identity provider.
• Managed policy settings centrally enforce tool permissions, file-access limits and connector (MCP-server) configuration across all coding-assistant users (the primary control against excessive agency in AI-assisted development).
• A compliance/audit API streams typed events into the enterprise SIEM, replacing manual exports with a live feed.

Treat these as the model-specific layer of the architecture, applied to every model the same way, and confirm each provider's current capabilities at adoption time. 

Primer: A coverage gap to close deliberately 

A provider's compliance/audit API typically covers administrative and governance events but may not capture agent-level operational activity or network-layer data from a desktop agentic application. Do not assume the provider's audit feed gives full coverage of an agentic surface. Close the gap with the planes you already own, endpoint and EDR telemetry, browser-level capture and network/DLP inspection of model traffic, so that what the provider's API cannot see, your own enforcement points do. The principle: assume every model provider's native logging has blind spots that must be covered with your own telemetry.

Primer: Provider safety frameworks are defense-in-depth, not a substitute 

Leading providers run model-side safety programs such as Anthropic's ASL-3, part of their Responsible Scaling Policy. ASL-3 is a precautionary standard, applied to frontier models that could materially increase catastrophic-misuse risk or show low-level autonomy, and it has two parts. A Deployment Standard adds a narrowly targeted set of safeguards, real-time classifiers and layered monitoring, that limit misuse for chemical, biological, radiological and nuclear (CBRN) harms. A Security Standard adds more than 100 controls, such as egress-bandwidth limits, two-party authorization and hardware security keys, that harden protection of the model weights. Together these raise the assurance you can place in the model you consume, but they target catastrophic safety harms and weight theft, not your data-loss, identity or agentic-containment needs, so treat them as one input to your control set, never a replacement for it.

Reducing the number of endpoint agents

Enforcing in many places must not mean installing many agents. Every additional endpoint agent is more software to deploy and patch, another supply-chain dependency, another potential conflict and another way a faulty update can disrupt the device. The architecture collapses functions that have historically shipped as separate products onto a single extended detection and response (XDR) agent, endpoint detection, data-loss prevention, zero-trust access and device posture in one, plus one governed enterprise browser for AI-usage visibility and in-browser DLP. Network, cloud and AI-guardrail capabilities move off the endpoint entirely into the Secure Service Edge and cloud planes. The target is roughly two managed components on a device instead of five or more; fewer agents also means cleaner, better-correlated telemetry and less performance drag, which reduces the friction that pushes users toward unsanctioned AI.

Capability coverage: overlaps and gaps

Consolidation only works if you can see where products do the same job. The matrix below maps the architecture's capabilities against the categories of platform that provide them: a single endpoint XDR agent; a Secure Service Edge; a governed enterprise browser or extension; a cloud platform for identity, data security, posture and SIEM; the provider's native controls; and a small set of specialist tools that fill what the platforms do not. Capability categories are used throughout; WWT can advise on specific products for each category for a given environment. 

Two patterns matter. Overlaps are where several products can perform the same capability, data-loss prevention, for instance, exists in the XDR agent, the enterprise browser, the Secure Service Edge and the cloud platform's data tooling all at once; browser visibility is offered by a dedicated enterprise browser, by an SSE's own browser and by the managed enterprise build of the standard browser; cloud posture appears in the SSE's cloud module, the cloud platform's native CNAPP and best-of-breed tools alike.

Overlaps are not redundancy to celebrate: each duplicated capability is another agent, another console and another license, so the discipline is to choose one primary owner per capability and deliberately switch the others off. Gaps are the opposite problem highlighting capabilities the consolidated platforms cover thinly or not at all, where a solution specialist is genuinely needed. The recurring gaps are AI prompt and response guardrails (depth beyond what the platforms include natively), model and AI supply-chain security and non-human or agent identity with just-in-time access.

Table 2. Worked-stack capability map (categories only). Primary owner is where to consolidate; the overlap column lists categories to disable for that capability; the gap column flags where a specialist is needed. WWT can advise on specific products for a given environment. 

Securing the agentic surface

Agentic AI changes the problem. An agentic desktop assistant acts across a user's files and applications, and a coding assistant invokes tools and connectors (MCP servers) as it works. That shifts the question from "is this action allowed?" to "is this action's intent aligned?", a runtime decision over principal, action, resource and context, not a static role check. Agentic risks (OWASP's Top 10 for Agentic Applications, ASI01–ASI10) do not replace the foundational and generative-AI layers below them; they amplify them, with prompt injection as the delivery vector and identity scope, tool design and egress control deciding the damage. 

Primer: Triage every agent with the lethal trifecta and the Rule of Two 

The lethal trifecta (Simon Willison, 2025) is the dangerous combination of access to private data, exposure to untrusted content and the ability to communicate externally; an agent with all three can be turned, by a single poisoned input, into an exfiltration channel with no traditional code vulnerability. Meta's Agents Rule of Two (2025) makes this actionable: an agent should satisfy at most two of those legs in a session, and if it genuinely needs all three it must run under human-in-the-loop or be split architecturally. Practical ways to break a leg: a dual-LLM / two-agent design (a quarantined model reads untrusted data; a privileged model holds the tools); a strict egress allow-list with DLP; and capability or provenance tokens that make tools refuse tainted inputs. Provider managed-policy settings that restrict which tools, files and connectors an agent may use, reinforce this.

Architecturally, the agent is best modeled as a pipeline of trust boundaries, each with its own policy-enforcement point (PEP), shown in Figure 4. The planner, the reasoning model itself, is the subject of enforcement, never a PEP, because it cannot police itself once injected. Each PEP must fail closed on a policy-engine error and emit telemetry; without those two properties it is hope, not enforcement. 

The numbered badges in Figure 4 follow a request through the zones in order: (1) the Input PEP validates, classifies and taints untrusted input; (2) the Memory PEP gates reads and writes to memory and RAG, with isolation, TTL and provenance; (3) the Tool and MCP gateway authorizes tool calls with least privilege and parameter limits; (4) the Sandbox PEP isolates execution (microVM, blocked instance-metadata service, egress deny); (5) the Output PEP validates, filters and sanitizes responses before release; (6) the Egress PEP allowlists destinations to stop exfiltration; and (7) the A2A bus PEP authenticates and authorizes agent-to-agent messages with signed cards, mTLS and replay protection. 

Figure 4 shows where enforcement happens; behind each point sits a full policy architecture, the AI security harness. The harness is the runtime that wraps the model or agent and owns enforcement on its behalf. A policy-enforcement point (PEP) intercepts an interaction and acts on a decision, but it does not make that decision: the decision comes from a policy-decision point (PDP), which evaluates the request against policy and context and returns permit, deny or obligations. 

The policy the PDP applies is authored, versioned and published from a policy-administration point (PAP), which also holds the policy store; the context it needs, identity, data classification, taint and provenance, risk and threat signals, comes from a policy-information point (PIP). Circuit breakers and the L1-L5 ladder (see following Primer: WWT's graduated L1–L5 response ladder) give the harness a graduated response, and every PEP and PDP decision is logged to the SIEM as evidence. Because the harness, not the model, owns enforcement, the same controls carry over to any foundation model. Access-layer enforcement at the PEPs is complemented by data-layer governance: classifying, masking and enforcing entitlements at the data asset itself, which is where privacy-regulation compliance is ultimately decided. Figure 5 shows the full stack. 

Primer: WWT's graduated L1–L5 response ladder 

WWT developed this L1–L5 ladder as a practical model for graduated agent response; the principle is to pick the lowest tier that contains the threat. L1, Soft degrade: keep running but restrict (read-only tools, a cheaper model, disable destructive actions). L2, Human-in-the-loop: pause and require explicit approval before the next tool call. L3, Session halt: terminate the run, preserving state/checkpoint for inspection or safe resume. L4, Credential revocation: revoke the agent's tokens (OAuth, SPIFFE, IAM) so it fails closed on its next action, used when the agent itself may be compromised. L5, Global kill: revoke credentials and halt agents fleet-wide, the "stop everything" switch when a problem may be spreading. 

These capabilities follow the same overlap-and-gap pattern as the rest of the architecture. The input, output and egress PEPs largely reuse the AI gateway, guardrail and Secure Service Edge capabilities already in place, and agent telemetry flows into the same SIEM; the genuine current gaps are memory isolation and provenance, tool/MCP supply-chain integrity, deterministic circuit breakers and agent-to-agent trust.

Table 3. Agentic policy-enforcement zones, what each enforces, the tooling category and whether it is covered by consolidated platforms or remains a gap. OPA, Cedar, SPIFFE/SPIRE and the sandbox runtimes are open-source projects/standards; WWT can advise on commercial products for a given environment.

Primer: What is OPA? 

Open Policy Agent (OPA) is an open-source, general-purpose policy engine, a graduated Cloud Native Computing Foundation (CNCF) project, that separates authorization decisions from application code. Policies are written declaratively in Rego and evaluated by OPA as a policy decision point: a service hands OPA a structured request (who is calling, what action, which resource, in what context) and OPA returns allow or deny, with optional obligations such as requiring human approval. In this architecture, the decision engine behind the tool/MCP gateway PEP, the protocol and OAuth establish who is calling and which server a token targets, while OPA answers whether this agent may invoke this tool, on this resource, right now. Because policy ships as versioned, testable bundles with decision logs, agent permissions become auditable policy-as-code rather than rules scattered across tool servers. 

Containment and agent identity

Two distinct controls limit blast radius, and an agent needs both: sandboxing prevents escape, tool code runs in a kernel-isolated microVM with capabilities dropped, a read-only root, default-deny networking and the cloud metadata endpoint blocked, while circuit breakers prevent runaway, halting, degrading or handing off through WWT's graduated L1–L5 ladder when aggregate session signals (cost, semantic looping, scope drift, policy violations) cross a threshold. Provider model-side classifiers act as one input to the breaker, not a substitute.  

Underpinning all of it, every agent is a non-human identity to be treated as a privileged workload: no long-lived credentials in its runtime, a cryptographic workload identity (for example SPIFFE/SPIRE) with an accountable owner and tokens minted just-in-time at each tool call via exchange (RFC 8693), audience-bound, proof-of-possession (DPoP or mTLS) and expiring in minutes. If an agent shares the user's session token, containment is already lost.

Primer: What are SPIFFE and SPIRE? 

SPIFFE (Secure Production Identity Framework for Everyone) is a standard for secure workload identity, a vendor-neutral way to give every workload a verifiable, cryptographic identity instead of a shared secret or static key. SPIRE is its runtime implementation, automating identity issuance and verification across diverse environments. They are the mechanism behind the agent-identity guidance: each agent and tool presents a short-lived, attested identity at every call, so access can be scoped and continuously verified rather than relying on long-lived credentials. 

Control, log and ownership mapping

A control is only operational if someone owns it and it produces evidence. The table below maps the architecture's principal controls to where they are enforced, the logs they generate and the team that typically owns them. Use it to assign accountability and to confirm that every enforcement point feeds the SIEM.

Table 4. Control-to-log-to-owner mapping. Every enforcement point should produce evidence and have a named owner; all feed the SIEM for correlation. 

Detection and incident response

The same signals that drive runtime enforcement also drive detection and response. Build a few high-value detections first: sensitive data or secrets in a prompt or upload; egress to an unsanctioned AI domain (shadow AI); a burst of policy-denied or out-of-scope tool calls; a non-human identity acting outside its baseline; and a semantic loop or cost spike indicating a runaway agent. Map each detection to a tier in the graduated L1–L5 ladder so the SOC's response is predetermined, and fold these into existing incident-response runbooks rather than a parallel process, extending them for AI-specific containment (halt and checkpoint the session, revoke the agent's short-lived credentials, quarantine poisoned memory or a malicious tool) and capturing the reasoning trace and decision logs as evidence. 

Deployment maturity model

Most organizations cannot stand up the full architecture at once, and shouldn't. The maturity model below sequences adoption across three stages, pilot, production and scaled operations, so coverage deepens with confidence and the controls that matter most for a given level of autonomy come first. 

Table 5. Deployment maturity model. Sequence coverage from pilot to scaled operations; let control depth scale with the autonomy of what you are deploying. 

Applying the architecture to other foundation models

Nothing in this design is specific to the worked example beyond the names in the provider-native layer. To govern any other external model, or an enterprise-hosted open model, the four planes are unchanged: endpoints and browser enforce close to the user, the Secure Service Edge inspects and controls egress, the cloud plane supplies identity, data security, posture and the SIEM, and the identity spine binds every interaction. Only the model endpoint and the provider-native control set change.  

For each new model, ask the same three questions:  

• How is access bound to identity?
• What does the provider's native logging cover and where are its blind spots?
• What data is allowed to reach it?

The worked stack and its overlap/gap map carry over directly; a new model rarely adds a new capability and simply attaches to the egress and governance controls already in place. 

Fitting into a broader AI-security program

This is deliberately a usage-security architecture: it secures how foundation models are used. It is designed to slot into a broader program. WWT's ARMOR, the AI Readiness Model for Operational Resilience, is one such program: a vendor-agnostic framework developed with NVIDIA that secures AI across its full lifecycle. In its latest version (ARMOR v2), it organizes the work into seven domains, the newest of which is Identity Security:

• Governance, Risk & Compliance
• Model Protection
• Secure AI Operations
• Infrastructure Security
• Identity Security
• Data Security
• Secure Software Development Lifecycle

Resilience, the "R" at the heart of ARMOR, is not a separate domain but a natural outcome when maturity is achieved across all seven domains, helping the AI estate withstand, contain and recover from failure and attack. Identity Security, the newest addition in WWT's latest ARMOR, is now a domain in its own right, spanning human, machine and non-human identity: multi-factor and passwordless authentication, role- and attribute-based access, zero-standing privilege, vault-based secrets, machine identity management and federated identity.

Viewed through that lens, this guide is the operational reference architecture for a subset of those domains rather than the whole program (Figure 6). Its enforcement planes and guardrails realize Secure AI Operations, Infrastructure Security, Identity Security and Data Security, binding human and non-human identity to every interaction; it contributes to Model Protection through model and AI supply-chain controls; and its containment design (sandboxing, circuit breakers and the graduated response ladder) contributes directly to the Resilience that spans every domain. The remaining ground, enterprise-wide governance and risk management, model protection beyond usage and a secure SDLC for AI-assisted code, is where a full program extends past this document. Positioning the architecture within a broader program keeps control decisions tied to an ongoing, measurable capability.

Conclusion 

Securing foundation-model usage is less about any one model than about the architecture around it. Treat the chat, coding and agentic surfaces as one estate; enforce at the endpoint, browser, network and cloud while keeping the endpoint light; bind every prompt and action to an identity, including the non-human ones; govern the model loop with guardrails on input and output; and add the agentic controls, sandboxing, circuit breakers and just-in-time identity, that autonomy demands. Consolidate wherever capabilities overlap so the estate runs on fewer agents and fewer consoles and consider a specialist solution only where the platforms leave a real gap. Do that, and the same design that secures today's worked example secures the next foundation model just as readily, turning AI from an ungoverned risk into a capability the enterprise can adopt with confidence. 

Work with WWT

Every environment is different, and the right combination of platforms and specialist controls depends on your estate, risk tolerance, regulatory obligations and existing investments. World Wide Technology can help translate this architecture into a plan for your organization, assessing your current state, mapping controls to the ARMOR domains, validating designs in our Advanced Technology Center and recommending and integrating specific solutions for your needs. Reach out to WWT to discuss your specific needs, requirements and solutions at wwt.com.

Ready to get started?

Appendix

Appendix A: what this guide does not solve

Being explicit about the boundaries is part of being defensible. This architecture secures the usage loop; it is not a complete AI-security program, and it does not, by itself, do the following:  

• It does not replace enterprise-wide AI governance, model protection beyond usage or a secure SDLC for AI-generated code, which are adjacent domains it plugs into.
• It does not fix a weak data-classification program: guardrails can only act on data that has been discovered and labelled, so poor classification limits everything downstream.
• It does not address model quality, accuracy or hallucination as business risks, which require human review, evaluation and process, not security controls.
• It does not eliminate residual risk: a prompt-injected agent acting within a legitimately granted, short-lived scope can still cause harm, and novel attacks will bypass point-in-time controls.
• It does not substitute for organizational change, since training, acceptable-use norms and incentives determine whether people work with the controls or around them.
• it is not a procurement decision: specific products are best selected with WWT for your environment, their capabilities change and partnership and suitability must be assessed independently.

Appendix B: acronyms and abbreviations

Expansions for the acronyms and abbreviations used in this guide. 

References and further reading 

Sources consulted in preparing this guide, grouped by topic. Links were current at publication (accessed June 2026); confirm provider capabilities and document locations against current sources before relying on them. 

Frameworks and standards 

NIST. AI Risk Management Framework (AI RMF 1.0), AI 100-1. 2023. nist.gov/itl/ai-risk-management-framework 

NIST. SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management (CSF 2.0 Community Profile). 2025. csrc.nist.gov/pubs/sp/800/61/r3/final 

NIST. SP 800-207, Zero Trust Architecture. 2020. csrc.nist.gov/pubs/sp/800/207/final 

NIST. SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations. csrc.nist.gov/pubs/sp/800/162/upd2/final 

OASIS. eXtensible Access Control Markup Language (XACML) Version 3.0, the PAP/PDP/PIP/PEP model. 2013. docs.oasis-open.org/xacml/3.0 

Agentic and AI threat research 

OWASP Gen AI Security Project. OWASP Top 10 for Agentic Applications (Agentic Security Initiative). 2025. genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026 

Willison, S. The lethal trifecta for AI agents: private data, untrusted content and external communication. 16 June 2025. simonwillison.net/2025/Jun/16/the-lethal-trifecta 

Meta. Agents Rule of Two: A Practical Approach to AI Agent Security. 2025. ai.meta.com/blog/practical-ai-agent-security 

MITRE. ATLAS, Adversarial Threat Landscape for Artificial-Intelligence Systems. atlas.mitre.org 

MITRE. D3FEND, defensive countermeasures knowledge graph. d3fend.mitre.org 

Identity, policy and telemetry 

SPIFFE / SPIRE, Secure Production Identity Framework for Everyone. CNCF. spiffe.io 

Open Policy Agent (OPA) and the Rego policy language. CNCF. openpolicyagent.org 

Cedar, open-source authorization policy language (Apache 2.0). cedarpolicy.com 

Zeigeist. AuthZEN, Cedar, OPA and Zanzibar-style FGA: a comparison. medium.com/@Zeigeist/authzen-cedar-opa-and-zanzibar-style-fga 

IETF. RFC 8693, OAuth 2.0 Token Exchange. datatracker.ietf.org/doc/html/rfc8693 

IETF. RFC 9449, OAuth 2.0 Demonstrating Proof of Possession (DPoP). rfc-editor.org/rfc/rfc9449.html 

OpenTelemetry. Semantic conventions for generative AI. opentelemetry.io/docs/specs/semconv/gen-ai

Fowler, M. CircuitBreaker (pattern; see also Nygard, M., Release It!). martinfowler.com/bliki/CircuitBreaker.html 

Regulation 

European Union. AI Act (Regulation (EU) 2024/1689), Article 12, Record-keeping. artificialintelligenceact.eu/article/12 

European Union. AI Act (Regulation (EU) 2024/1689), Article 14, Human oversight. Consolidated text on EUR-Lex. eur-lex.europa.eu/eli/reg/2024/1689/oj 

Foundation-model provider, worked example: Anthropic Claude 

Anthropic. Responsible Scaling Policy (v3.0). anthropic.com/responsible-scaling-policy 

Anthropic. Activating AI Safety Level 3 (ASL-3) protections. 2025. anthropic.com/news/activating-asl3-protections 

Anthropic. Claude enterprise controls: single sign-on, managed policy and the Compliance API; confirm current capabilities at adoption. support.claude.com 

WWT resources 

WWT. ARMOR press release January 2026. wwt.com/press-release/world-wide-technology-unveils-armor-a-collaborative-ai-security-framework-with-nvidia-ai  

WWT. ARMOR, AI Readiness Model for Operational Resilience (overview). wwt.com/atc-capabilities/ai-readiness-model-for-operational-resilience/overview 

WWT. AI Security (topic hub and research). wwt.com 

Scope and methodology notes 

Specific products are intentionally not named in this public guide; WWT can recommend and validate solutions for a given environment. Assess any vendor or product for current capabilities, ownership and suitability before selection. 

WWT's L1–L5 containment ladder is operational shorthand, not an industry standard. It maps to the circuit-breaker pattern (CLOSED / OPEN / HALF-OPEN) as the trip mechanism; NIST SP 800-61r3 (CSF 2.0 Respond) graduated containment for L1–L3; Zero Trust continuous access evaluation (NIST SP 800-207) for the credential-revocation tiers L4–L5; with actions optionally tagged to MITRE D3FEND (Isolate / Evict / Restore). 

Make a new world happen 

This guide is World Wide Technology thought leadership for public distribution. Vendor names are illustrative examples of solution categories, not endorsements. Validate product capabilities, ownership and provider logging coverage against current sources before relying on them. 

World Wide Technology · wwt.com