Governança para a execução agêntica

Security cannot be retrofitted at the model or network layer alone. It has to be anchored in an agentic control plane that continuously governs visibility, connectivity, and execution.

The Governance Gap: Five Questions Every Board Is Asking

AI agents are multiplying faster than most security teams can keep track of. Gartner predicts that by 2028, an average global Fortune 500 enterprise will have over 150,000 agents in use, up from less than 15 in 2025, generating significant agent sprawl, IT complexity and management challenges. Only 13% of organizations think they have the right AI agent governance in place. That gap is why cybersecurity and compliance committees keep coming back to the same five questions.

1. Where are our AI agents, and who owns them?
2. How do we restrict what agents can execute and stay on task?
3. Can we audit and explain autonomous decision-making after the fact?
4. What is our data exposure and third-party risk across the agent supply chain?
5. Do we have a verified kill switch and rollback plan if an agent goes rogue?

These five questions map onto the four pillars of the Blueprint reference architecture in Section 3. Discovery and identity registration answer question one, Access Management answers question two, Runtime Authorization and Monitoring answers questions three and four, and Active Containment answers question five. Answering these five questions with evidence, not just assurances, lets a CISO safely accelerate agent adoption while matching control depth to regulatory and operational exposure. Those who cannot remain vulnerable to significant and increasing security incidents.

These questions serve as a diagnostic tool to evaluate risk rather than a uniform checklist. Security requirements naturally vary by operational scope, as a read-only productivity assistant does not need the same containment controls as an agent executing financial transactions. Diagnosing which risks actually apply allows security teams to match controls to real-world exposure. This keeps organizations from over-engineering low-risk deployments and slipping into multi-month approval delays, while ensuring high-risk agents receive appropriate operational boundaries.

The Blueprint Reference Architecture grounds agentic enterprise security in four operational questions required to govern autonomous execution, each mapping to a pillar of the reference architecture:

1. Where are my agents? 
2. What can they do?
3. What are they doing?
4. How do I respond?

Spanning all of these questions is the need for a strong foundation of execution context and risk signals, fed continuously by runtime telemetry, logging, and observability. Together, these act as the connective tissue that enables the system to see risk patterns, and respond in concert.

3.1 Pillar 1: Where are my agents? (Development, Discovery & Identity)

The foundational challenge of securing the agentic enterprise is visibility. Organizations cannot govern or protect what they do not know exists. This pillar establishes a comprehensive tracking capability across all corporate environments to identify, catalog, and evaluate every AI agent traversing the corporate infrastructure, whether sanctioned or unmanaged. This pillar concludes by registering validated agents as governed identities with accountable owners, producing the authoritative inventory that Pillar 2 binds access policies to.

3.1.1 AI Agent Discovery

AI Agent Discovery serves as the continuous detection mechanism for the enterprise agent footprint. It maps the complete lifecycle of agents from internal engineering pipelines to external third-party integrations, ensuring that no active model or autonomous process operates in a blind spot.

3.1.1.1 Agent Development

This component focuses on internal engineering environments where proprietary agents are actively built, trained, and tuned. Securing the development pipeline helps ensure security-by-design before an agent ever interacts with production data.

• Agent platforms: Enterprise-managed orchestration environments where agents are hosted, trained, and systematically deployed.

• Agent frameworks: The underlying software libraries and architectures (such as LangChain, LlamaIndex, or AutoGen) utilized by developers to build agentic logic.

• LLM models: The foundational and fine-tuned large language models that serve as the cognitive engines driving the agents.

• Isolated build and execution environments: Secure, compute-isolated CI/CD boundaries that run agent code during testing and evaluation, ensuring security teams discover ephemeral test executions rather than relying solely on static registry declarations.

• Additional internal tooling: Custom code repositories, code assistants, and internal model registries integrated into the development pipeline.

• Skills: Defined procedural modules, code snippets, or tools built out to extend the capabilities of an agent.

3.1.1.2 Agent Import

Modern enterprises rarely rely solely on a single source of intelligence; instead, they ingest diverse agent architectures that vary by origin, framework, and compute boundary as a hedge against rapidly shifting agentic capabilities. Agent Import monitors and governs the introduction of these varying agent classes into the corporate ecosystem, focusing heavily on how data flows across the organization based on their underlying deployment model.

Agent Type, Category, and Channel are three separate questions you can ask about any agent you import, and a single agent will usually have an answer to all three at once, for example, a SaaS agent (built by a vendor) used for internal HR workflows (B2E), pulled in through an agent gateway.

• Agent Type: Who built it?

  • First-party agents: Internally developed AI capabilities ranging from fully custom implementations built with raw code (such as Python and LangChain) running on general-purpose compute (e.g., Kubernetes or Serverless Functions), to agents constructed using provider-specific agentic frameworks that natively handle the runtime, memory, and workflow orchestration.

  • SaaS agents: Purpose-built, third-party AI products that operate as entirely independent entities within the enterprise software ecosystem.

  • Local agent: A client architecture installed directly on the employee's local device, where every single reasoning step is sent to a remote cloud LLM provider. It behaves as a non-deterministic layer between human intent and tool action, with data crossing the organizational boundary on every inference call.

  • Orchestration agents: Agents built on visual orchestration platforms that serve to "glue" disparate enterprise APIs together.

• Agent Category: Who is it for?

  • B2E (Business-to-Employee) agents: Internal, employee-facing AI agents deployed to automate corporate workflows, IT/HR operations, and daily employee productivity within internal enterprise identity and role-based access controls

  • B2B agents: Business-facing AI agents that operate across corporate boundaries to automate enterprise-to-enterprise workflows, supply chain transactions, and cross-tenant API integrations.

  • B2C agents: Consumer-facing AI agents deployed to interact directly with external end-users for service, commerce, or support, requiring strict defenses against public prompt injections, brand exposure, and consumer PII leaks.

  • B2B2C agents: White-labeled or vendor-provided AI agents delivered through a corporate client to serve that partner's end-consumers, operating under multi-tier isolation and transitive trust boundaries.

  • Personal Assistant agents: Consumer-grade, user-directed AI assistants operating on an individual's behalf across both personal and enterprise contexts, requiring boundary controls between personal and corporate data access.

• Ingestion Channel: How is it found?

  • Agent gateways: Ingestion points and proxies through which these external or imported agent types interact with internal enterprise APIs.

  • Ecosystem registries & third-party catalogs: Automated connector pipelines and API adapters that continuously monitor, pull, and map agent definitions from external vendor-native registries, ensuring agents are automatically cataloged without intervention.

  • MCP & Skill registries: Ingestion points through which agents pull tool schemas, skills, and context definitions from public or vendor-hosted MCP and Skill registries. Registries are themselves an injection vector; a malicious or disguised entry can be pulled in and consumed automatically, so every registry-sourced tool or skill is treated as untrusted input subject to the supply-chain scanning in Section 3.1.2 before an agent can invoke it

3.1.1.3 Shadow AI Discovery

Employees naturally turn to unapproved AI tools to optimize their workflows, introducing compliance, data exfiltration, and operational security risks. Shadow AI Discovery actively scans corporate perimeters to detect unauthorized agent deployments and usage. Discovery and monitoring capabilities should be implemented in accordance with applicable privacy, employment, labor, works-council and data-protection requirements, with appropriate transparency, proportionality, data minimization, retention and access controls.

• Cloud infrastructure: Cloud compute instances, serverless environments, and unmanaged API endpoints discovered via active network/API inspection.

• Network: Real-time traffic analysis and egress monitoring to identify unrecognized API calls to external LLM providers and AI endpoints.

• Endpoint: Device-level monitoring to track unauthorized execution of AI binaries, scripts, or local model weights.

• Browser: Extension tracking and browser session monitoring to detect when users log into unapproved web-based AI platforms or chat systems.

• Mobile Device Management (MDM) & Endpoint management: Continuous device-level auditing to detect unapproved local AI executables, local model weights, CLI agent tools, and IDE extensions, while enforcing baseline security posture and blocking unmanaged agent runtimes at the operating system layer.

• IoT, OT & edge infrastructure: Industrial security monitoring and network protocol inspection to detect Small Language Models (SLMs) and autonomous agents on manufacturing equipment, PLCs, and embedded hardware where traditional endpoint software cannot be deployed. 

• Mail and collaboration flow: Analysis of message, chat, and calendar traffic to detect unsanctioned agents sending messages, auto-replying, or managing calendars on a user's behalf before activity becomes visible in endpoint or network egress logs.

• Governed execution path as a detection surface: An architectural boundary where all sanctioned agents execute through a centrally managed control plane; any agentic process operating outside this boundary is automatically flagged as a shadow AI signal without requiring separate environment-specific detection rules.

3.1.2 AI Agent Security Posture Management (AIASPM)

Once discovered, agents must be continuously evaluated. AIASPM provides the diagnostic layer that assesses risk profiles, configuration hygiene, and known software weaknesses across the entire agent inventory.

• Risk Inventory: A centralized, dynamic ledger tracking security posture, vulnerabilities, software dependencies, and misconfigurations across discovered agents regardless of lifecycle state, provisioning the security-risk lens to complement the IAM-focused Agent Directory.

• Vulnerabilities: Standard software vulnerability management extended to agentic dependencies and model endpoints, covering CVEs across the agent's codebase, supply chain, and foundational models, mapped to standardized frameworks for consistent risk scoring.

• Code & image provenance: Cryptographic verification of the origin, build integrity, and signatures of agent code, container images, dependencies, and model weights (e.g., SLSA framework attestations) prior to production execution. Utilizing minimal, pre-attested base images stripped of unneeded packages and rebuilt against current CVE data reduces supply chain attack surface and simplifies provenance verification at build time.

• Tool & skill supply-chain scanning: Automated static and dynamic inspection of local agent instruction sets, execution skills, and remote Model Context Protocol (MCP) tool schemas, including entries pulled from MCP and Skill registries, to detect embedded malicious code, concealed operations, and unauthorized egress paths prior to registration.

• Misconfigurations: Continuous scanning to catch weak parameter settings, insecure system prompts, hardcoded long-lived credentials, impersonation vectors and configuration drift introduced after an agent's initial review passed.

• Adversarial validation: Continuous, automated adversarial testing of agents and their guardrails against known prompt injection, jailbreak, and data-exfiltration paths inside disposable, isolated execution boundaries to safely evaluate real-world exploitability without risking production impact. 

3.1.3 Agent Directory (Register and govern agent identity)

Where Agent Import (Section 3.1.1.2) captures provenance and metadata during discovery, the Agent Directory is the authoritative identity repository where cryptographic credentials, ownership, and policy entitlements are formally registered and maintained for all validated, enterprise-hosted agents. Registration is the boundary between a discovered agent and a governed one, and it is the prerequisite for every access decision in Pillar 2.

Every hosted agent and every sub-agent with distinct entitlements must be registered here with a verified profile, cryptographic identity, accountable owner, and clear structural relationships before it can request access to enterprise systems. Keep registration lightweight enough that it doesn't push teams to bypass it by using shared human credentials. Local agents and ephemeral sub-agents that inherit a parent's scope are governed by the containment and delegation controls described below rather than by individual directory entries. Once an agent is imported, the Directory answers two more questions about how it operates in your enterprise: what role does it play and how does it prove its identity.

• Agent Classes: What role does it play?

  • Autonomous agents: Fully independent agents that operate asynchronously to achieve long-running business goals without immediate human oversight.

  • OBO (On-Behalf-Of) human agents: Agents executing tasks directly tied to a specific human user's session, acting as a proxy and constrained by that user's underlying permissions.

  • Orchestrator agents: Parent-level agents that decompose an objective into sub-tasks and spawn, coordinate, and supervise downstream sub-agents; the directory must track delegation chains and spawn relationships as first-class attributes. 

  • Sub-agents: Specialized child agents dynamically spawned or invoked by a parent orchestrator to execute discrete sub-tasks, governed by inherited session scopes rather than individual directory registration. Because in-model task boundaries enforced within an LLM can fail, sub-agents must be wrapped in isolated execution boundaries that structurally enforce inherited permission scope, preventing reasoning errors from escalating privileges.

  • Physical/Embodied agents: Agents controlling robotics, actuators, or other physical systems. This architecture governs identity and access, but complements, rather than replaces, existing plant safety, OT security, and change-management controls.

  • Guardian & Security agents: Specialized administrative AI agents operating within the security control plane (e.g., SOC triage agents, dynamic policy engines, continuous ASPM scanners). Given their elevated privileges to inspect telemetry and execute containment actions, guardian agent identities require mandatory cryptographic workload attestation, strict separation of duties, and continuous owner sign-off. 

• Identity Substrate: What proves it’s really that agent?

  • Agent Identity metadata profile: Rich metadata profiles (CIMD) that define the agent's intent, origin, lineage, and operational context to inform risk-based access decisions.

  • Workload identity: Cryptographic, platform-agnostic, standards-based identity production frameworks used to issue secure, verifiable IDs to agents across dynamic cloud environments.

  • Agent governance metadata: Structured metadata bound to the agent's directory record, including its accountable human owner, designated operational team, or on-call queue, lifecycle status (e.g., active, suspended, retired), risk tier, and operational scope, to be used continuously by policy engines for access control authoring and runtime evaluation. 

  • A2A agent protocols: AI agents that leverage standardized interoperability frameworks to dynamically discover capabilities, delegate tasks, and collaborate peer-to-peer across enterprise boundaries. When interacting across organizations without a shared directory or trust root, agents utilize cryptographic attestation and token-exchange standards (e.g., WIMSE/AIMS, OAuth Token Exchange, HTTP Message Signatures) to preserve delegation chains and verify principal identity across intermediaries.

3.2 Pillar 2: What can they do? (Access & Entitlements)

Autonomous agents are fundamentally designed to act, which requires them to connect to data, APIs, and systems. Building on the verified identities established in Pillar 1, this pillar defines the boundaries and permissions that govern how agents interact with corporate resources across both direct human-delegated sessions and complex, multi-agent workflows, augmenting legacy human-centric models with machine-to-machine AI governance.

3.2.1 Access Policies (Define access policies)

Access Policies specify the operational boundaries for what an identity-verified agent is allowed to read, write, or execute. Given the unpredictable nature of generative AI outputs, these policies must be deeply contextual and adaptive.

• Coarse-grained: Broad, role-based controls defining which high-level environments or macro-services an agent can connect to.

• Fine-grained: Attribute-based and object-level permissions restricting an agent to specific database rows, files, or specific API methods, explicitly taking into account corporate data classification labels (e.g., Confidential, PII) to enforce compliant data boundaries. Policy constructs may span data classification, agent identity, risk scope, environmental context, and action type.

• Relationship-based: Access derived from an agent’s graph relationships: who spawned it, who it acts on behalf of, and what it’s nested under. 

• Intent-based: Advanced policy engines that analyze the semantic intent of the agent's prompt or plan before granting access to resources. Inspecting a plan is achievable with current tooling; treating a literal user prompt as the sole trigger is aspirational, since prompts aren't always what an agent acts on. Ephemeral, time-bound privileges are created strictly for the duration of a specific task and immediately revoked upon completion.

• Network-based: Macro-segmentation restricting agent traffic across enterprise VPCs, combined with L3/L4 micro-segmentation controls restricting agent-to-target communication to authorized IP ranges or service meshes.

• Time-bound: Time-bound grants are scoped to a single task or session and are automatically revoked upon completion or timeout. Because auto-approved, auto-expiring grants add limited control value on their own, pair time-bound scoping with the anomaly detection in Section 3.3.1.2 rather than treating expiry alone as the safeguard.

• Cross-app access: Policy frameworks and boundary controls that govern an agent's ability to traverse distinct application ecosystems, enabling secure data translation, token exchange, and function execution as it orchestrates workflows across different enterprise platforms.

• Delegation & inheritance: The effective permission boundary for a sub-agent is computed as the intersection of its own entitlements and the delegating agent or human’s entitlements to prevent confused-deputy escalation. Policy should also cap the breadth and depth of delegation to prevent unbounded fan-out.

• Guardrails: Hard, deterministic safety constraints and behavioral boundaries that override autonomous reasoning loops to globally prevent non-compliant actions, toxic outputs, or high-risk operational steps regardless of the agent's intent or fine-grained privileges.

3.2.2 Governance

Governance provides the compliance baseline and continuous oversight loop, using automated tooling rather than manual rubber-stamp reviews to keep agent privileges aligned with the principle of least privilege at agent velocity.

• Contingent Review: Trigger automated or human-in-the-loop workflow approvals whenever an agent's action crosses defined financial or operational thresholds (e.g., a purchase or booking exceeding $1,000), regardless of whether the action falls within its granted technical permissions.

• Access reviews: Automated, continuous entitlement scanning helping system owners to validate non-conforming permissions.

• Access requests: Formal, audited workflows for provisioning new capabilities, models, or system access to an existing agent. While requests may originate from human owners or dynamically from agents at runtime, agent-initiated requests must be strictly evaluated against static permission ceilings and require mandatory owner verification for scope expansion to prevent agents from manipulating automated workflows into granting excessive access.

• Separation of Duties (SoD): Algorithmic rules preventing a single agent from possessing conflicting privileges, such as both generating and approving financial transactions.

• Joiner-mover-leaver (JML): Apply the same onboarding, change management, and deprovisioning discipline used for human identity lifecycles to an agent's scope, ownership, or model version evolution.

3.3 Pillar 3: What are they doing? (Runtime Authorization & Control)

Visibility and identity are ineffective without inline runtime monitoring and enforcement. This pillar focuses on intercepting, inspecting, and authorizing agent actions in real time as they execute tasks, ensuring they do not engage in malicious behavior, mishandle sensitive data, or compromise critical enterprise targets.

3.3.1 Runtime Authorization and Monitoring

Runtime Authorization and Monitoring serves as the active inspection layer for live agent sessions. It sits directly in the execution path, analyzing both the inputs flowing into the agent and the actions or outputs radiating back out.

3.3.1.1 Gateways (Enforce access policies)

Gateways act as policy enforcement points (PEPs) in a defense-in-depth chain. They intercept traffic between the agentic layer and the rest of the enterprise stack, parse protocols, and block unauthorized calls before they reach their destination. Downstream API Gateways maintain ultimate authorization authority, performing their own validation of every call regardless of what upstream AI/Agent Gateways have already inspected. AI/LLM, MCP, Security, Agent, and API Gateways are often deployed together, but each owns a distinct control point: AI/LLM Gateways govern model-API traffic; MCP Gateways govern tool/context-sharing protocol traffic; Security Gateways provide protocol-agnostic threat inspection; Agent Gateways govern agent-specific identity and delegation concerns; and API Gateways enforce classic API-layer controls for the tools and services agents call.

• AI/LLM gateway: Intercepts low-level API calls to foundational models, managing rate-limiting, token counts, and system-prompt overrides.

• MCP (Model Context Protocol) gateway: A specialized proxy optimized for managing context-sharing protocols and open-standard integrations between agents and applications with a focus on MCP servers.

• Security gateway: An inline threat-mitigation layer that provides dedicated content security and protocol verification for agent interactions. It sits directly in the traffic flow to perform real-time, TLS-terminating deep payload inspection, actively intercepting and filtering out complex prompt injections, jailbreaks, hidden adversarial text strings, and malicious code payloads before they hit the agent or downstream resources.  It also handles data classification scanning to enforce outbound data redaction, structural integrity checks on model outputs, and cryptographic inspection of encrypted agent payloads.

• Agent gateway: Serves as the agent-specific runtime control plane: binding agent identity to every request, maintaining the tool/MCP registry agents draw from, and governing agent actions, not just access, based on identity, context, and the specific action being requested. It stops unsafe interactions in real time, blocking or sanitizing risky model traffic and denying or requiring approval for sensitive tool actions via built-in and custom policies, and it injects secret-less, short-lived downstream credentials into API calls at execution time so agents never handle, store, or expose standing enterprise API keys or service account secrets. It can provide governed telemetry across supported multi-agent interactions and can detect or redact sensitive data, including PII, according to configured policies and capabilities while defending against unsafe behaviors and malicious prompt-based attacks.

• API gateway: Enforces classic API-layer controls, rate limiting, quotas, schema validation, mTLS, WAF, traffic shaping, and revoke-at-gateway for the tools and services agents and MCP servers use, performing its own final authorization check on every call rather than assuming upstream AI/Agent Gateways already caught every anomaly.

3.3.1.2 Monitoring (Monitor runtime)

Monitoring provides deep observability, threat detection, and active enforcement, scanning runtime telemetry for anomalous behavior, data leakage, and external exploitation attempts, and applying controls such as sandboxing and endpoint isolation in real time.

• Sandboxing: Isolating agent execution (especially untrusted, third-party, or newly updated agents) within secure, constrained runtimes to prevent lateral movement and contain execution risks through structural boundaries.

• Endpoint isolation & allowlisting: Local runtime controls for endpoint-hosted agents, including OS-level sandboxing, endpoint application allowlisting, and local device-posture checks to constrain local agent command execution and file access. 

• Tool/Data access: Real-time structural inspection and auditing of arguments, payloads, schemas, and queries passed to downstream tools and repositories. Performing inspection inside or directly adjacent to the execution boundary helps ensure dynamic execution plans do not deviate from authorized parameters or introduce unintended mutations mid-session.

• Threat/anomaly detection: Machine learning engines tracking agent behavioral baselines to flag unusual spikes in data access, rapid API loops, or bizarre execution patterns.

• Prompt injection: Inline scanners designed to catch adversarial text strings, both direct and indirect, meant to hijack the agent’s core logic or override system instructions.

• DLP / output filtering: Data Loss Prevention tools scanning agent outputs to mitigate the risk of leaking proprietary source code, PII, or trade secrets to external providers or unauthorized users.

• Tracing: Comprehensive transaction mapping that charts the exact execution path, call stacks, and sub-agent invocations triggered by a primary user prompt.

• Cost and performance: Tracking token usage, operational costs, latency, and resource consumption to prevent runaway agent loops or resource exhaustion attacks.

• Workflow-in-the-loop: Programmatic triggers that pause agent execution for high-risk actions, routing to automated policy cross-checks or explicit human sign-off before they proceed.

• Continuous Monitoring: Continuous monitoring and exportability of the agent’s activity, including granular tracing, audit trail logging, and non-repudiation of the agent’s actions. 

3.3.1.3 Continuous Intent and Alignment Enforcement

Continuous intent and alignment enforcement determines whether an agent remains within the boundaries of its delegated task throughout execution or has drifted into unauthorized purpose expansion. It complements initial access policies: intent-based policy determines what an agent may initially access, whereas continuous alignment enforcement evaluates whether evolving, multi-step behaviors remain appropriate over time.

Key capabilities include:

• Purpose binding: Enforcing strict linkage between the delegating user, agent identity, approved workflow, and requested task.

• Plan vs. action evaluation: Runtime comparison of planned tool calls against observed actions to catch task drift, injection-driven deviations, and confused-deputy behavior.

• Context-aware enforcement: Executing real-time actions, including allow, deny, redact, step-up approval, scope reduction, suspension, or containment.

• Traceable decision evidence: Maintaining non-repudiable audit logs explaining why each material action was allowed, modified, or blocked.

3.3.2 Resource Access

Resource Access delineates the actual blast radius of an agent. It categorizes the diverse downstream targets that an agent can interact with, helping ensure that appropriate security wrappers surround every interface.

3.3.2.1 Target Resources (Components being accessed)

Target Resources represent the destinations of an agent's actions. Whether pulling context or pushing changes, these endpoints must be continuously cataloged and defended.

• MCP servers: Data repositories and utility servers explicitly configured to share contextual information (structured data, documents, embeddings, tools, and state) with agents via the Model Context Protocol.

• SaaS apps: Enterprise productivity and core business applications containing vast stores of sensitive corporate data.

• Data stores & knowledge repositories: Structured and unstructured repositories, including vector databases, data lakes, warehouses, and transactional storage systems, leveraged by agents to extract business context or commit operational outputs. These repositories are governed by data security posture management (DSPM) practices that track lineage and classification as agents access each store.

• CLI tools: Command-line interfaces allowing agents to execute system-level scripts, configurations, or operational commands.

• Other agents: Downstream sub-agents or specialized agents tasked with executing fractional components of a broader workload.

• Privileged resources: Highly sensitive target environments, including root directories, identity stores, and master configuration consoles.

• Standard & Legacy endpoints: Enterprise REST/GraphQL APIs, databases, and legacy applications that do not natively support agentic context protocols like MCP.

• Payment systems: Financial networks, transaction gateways, and accounting ledgers require the highest degree of cryptographic validation and human oversight.

• Browsers: Web automated sessions utilized by agents to scrape public intelligence or interact with web-based external consoles.

• Skill runtimes & code executables: Code interpreters, script execution sandboxes, and procedural modules invoked dynamically by agents to run generated code, requiring isolated compute boundaries to mitigate runtime-escape risks. 

• Foundation models: The raw intelligence providers where weights are hosted, necessitating secure, validated model API keys.

• Communication and collaboration channels: Email, chat, and ticketing systems through which agents interact, representing untrusted prompt ingress paths subject to deep payload inspection and scanning. 

3.3.2.2 Purpose Aware Data Security 

Purpose aware data security evaluates whether a given agent should access, process, transform, summarize, disclose, or transmit specific data based on the delegated purpose, user authority, agent identity, workflow state, data classification, recipient, destination, and downstream action. It applies data controls at the moment of use, not only at the moment of access. This matters because agents combine data across systems, infer sensitive information from non sensitive inputs, and disclose results through outputs, APIs, messages, files, and sub agent calls. Classification and DLP determine what the data is and whether it is sensitive; purpose aware data security determines whether this use of it is appropriate in context. Key capabilities include purpose binding between the user request, agent task, data source, and permitted use; runtime evaluation of whether access and disclosure suit the current workflow step; controls for summarization, transformation, export, cross app movement, and third party agent disclosure; detection of data overreach, excessive retrieval, unauthorized inference, and inappropriate sharing; and enforcement spanning redaction, masking, partial response, approval workflow, logging, blocking, or containment.

3.4 Pillar 4: How do I respond? (Active Containment)

The final pillar of the blueprint transforms telemetry into immediate containment. When monitoring systems flag anomalous behavior, compromised credentials, or a prompt-injection attack, the enterprise must have highly automated, surgical mitigation mechanisms that favor proportional, least-disruptive responses (rate-limiting, quarantine) over destructive actions that could cause a self-inflicted outage.

3.4.1 Response/Enforcement (Throttling & Containment)

The automated operational control loop is designed to respond to risk signals in real time. It acts as a coordinated control layer, not a single centralized chokepoint, executing targeted, proportional security responses across the entire technical stack.

Enforcement is most effective when paired with a standardized notification protocol: the system that detects risk publishes a Kill Switch event, the subscribing systems act, and the outcome is published back as a confirmation signal.

3.4.1.1 Enforcement Actions (Mitigation mechanisms)

Enforcement Actions represent the concrete, multi-layered levers security teams and automated orchestrators can pull to isolate, contain, or completely neutralize a problematic or compromised agent. These actions form a SOC-owned library of response options, not isolated one-off switches: responders select the least-disruptive action proportional to the aggregated Risk signal. Containment actions triggered by guardian agents (suspend, isolate, terminate) require the target agent to operate within an execution boundary that supports granular session-level control, whether running in a managed cloud service, SaaS application, or containerized runtime. Without underlying platform or runtime support to pause an agent without collateral impact to adjacent workflows, API-driven containment provides a false sense of security. When containing agents tied to physical equipment or OT, automated triggers must be calibrated to ensure abrupt isolation doesn't create physical safety or operational hazards on the plant floor.

• Token revocation: Instantly invalidating active OAuth or API access tokens, immediately freezing the agent's ability to call connected applications.

• Session Token Revocation: Invalidating active OAuth tokens and revoking downstream session contexts across connected enterprise services and/or severing the active runtime connection of a single, specific interaction string without necessarily deleting the agent's broad identity.

• Continuous authorization: Dynamic, real-time re-evaluation of security contexts that instantly downgrades permissions the exact moment a risk posture changes.

• Process termination: Force-closing compute runtimes as a last resort when quarantine fails; note that termination sacrifices in-memory forensic telemetry, so prefer network quarantine, session suspension, or execution environment suspension where possible.

• Network quarantine: Utilizing micro-segmentation rules to isolate the agent's hosting environment, cutting off its communication with both the internal network and the open internet.

• Cloud service termination: Instantly shutting down the underlying cloud instances, serverless functions, or virtual machine clusters hosting the rogue agent.

• Agent platform termination: A top-level administrative command that instructs the centralized agent orchestration platform to suspend the agent's operational account and halt all scheduled tasks.

• Throttling and rate limiting: Progressively constraining an agent’s request rate, token budget, or concurrency as a proportionate first response, degrading capability without fully severing the session.

3.4.2 Access Recovery 

A kill switch is only half the control loop: every containment action needs a matching path back to a verified, last known good state. Access Recovery governs how a contained, quarantined, or terminated agent is restored to service, confirming that reinstatement is deliberate, documented, and traceable, rather than an automatic reversal of the enforcement action. Fully automated, standardized recovery workflows remain a target state; most organizations today still require manual sign-off at one or more of the steps below.

• Re-attestation: Re-verifying the agent's identity, code, and configuration against a known-good baseline before any access is restored in a fresh, isolated execution instance.

• Staged re-enrollment: Restoring access incrementally (e.g., read-only before write, sandboxed before production) rather than reinstating full privileges at once.

• Root-cause sign off: Requiring the human owner or security team to document root cause and remediation before re-enabling the agent.

• Audit trail closure: Linking the original Kill Switch event, remediation actions, and re-enrollment decision into one closed, auditable incident record.

3.5 Cross-Cutting Foundation Components 

These architectural layers do not live in silos; they sit underneath and across all four pillars, serving as the tissue that connects visibility, identity, monitoring, and response into a unified security fabric.

3.5.1 Execution Context & Risk Signals

Execution Context & Risk Signals serve as the connective analytical tissue of the blueprint. Fed continuously by real-time runtime telemetry, security posture assessments, and delegating user identity signals (such as account compromise indicators or elevated principal risk), this orchestration engine dynamically evaluates threats by correlating individually low-risk conditions into toxic combinations. It also publishes positive execution context, structural confirmation of what's already known to be valid, not just alerts about what's gone wrong. When a threshold is crossed (e.g., a sudden prompt injection combined with an attempt to exfiltrate financial data), Risk Signals trigger the corresponding Response/Enforcement mechanisms directly and programmatically. To help ensure real-time interoperability and coordinated responses across heterogeneous vendor environments, this system can leverage open security engineering standards such as the Shared Signals Framework (SSF) and the Continuous Access Evaluation Profile (CAEP) to asynchronously publish and consume zero-trust state modifications.

3.5.2 AI Agent Telemetry, Logging, and Observability

This is the foundational baseline layer supporting all pillars of the reference architecture. It serves as the immutable data plane, capturing execution metadata throughout the enterprise stack, backed by mandatory inline payload redaction to prevent PII, secrets, and credentials from entering the log lake. Without this structured, high-fidelity logging lake, automated threat detection is impossible, posture assessments lack data, and forensic incident responders are left completely in the dark. To help ensure consistency and reduce vendor silos in complex multi-agent interactions, this layer can leverage open standards such as the Open Cybersecurity Schema Framework (OCSF) to normalize diverse log streams into a single, unified security taxonomy.

• Tamper-resistance telemetry origin: Capturing telemetry at the execution boundary rather than relying on self-reported agent logs helps ensure non-repudiation, preventing a compromised agent from suppressing, modifying, or falsifying its execution record.