The agentic security operations center is no longer a research problem. It is a procurement category, a regulatory subject, and an architecture with named components, named control loops, and named failure modes.
The strategic case for replacing alert-first physical security with an autonomous, agentic operating model is now well documented in the published literature, including the IntelliSee Intelligence brief on autonomous security. What remains under-specified for the buyer, the architect, and the auditor is the layer beneath the strategy: the actual reference architecture. What are the named layers of an agentic security operations center? Which protocols connect them? Where is the human placed in the loop, and under what authority? What does the kill switch look like, and who is permitted to throw it? Until those questions have concrete answers, every vendor RFP response will read the same and every governance review will end inconclusively.
This report is the architecture reference. It is intended for security architects, CISOs, CTOs of building-systems integrators, and risk officers who need to evaluate, design, or govern an agentic security operations center for physical-security and workplace-safety risk. It synthesizes the 2025 and early-2026 standards work from NIST, the Cloud Security Alliance, MITRE, and ISO into a single layered model, names the human-in-the-loop checkpoints by class, walks the integration surface, and inventories the failure modes that ungoverned deployments routinely encounter. It closes with a procurement and audit checklist that converts the architecture into questions a buyer can put to a vendor and an auditor can put to a deployment.
Why an architecture reference is needed now
The vocabulary problem in agentic security is acute. A vendor saying their platform “uses AI agents” can mean a single LLM call wrapped in a retry loop, a deterministic playbook with a natural-language interface, or a true planning-and-tool-using agent with revisable plans. Buyers cannot procure responsibly across that spread, and auditors cannot review against it. The published standards bodies have begun to converge on a common architecture, but the convergence is not yet visible in vendor literature, which is where most procurement teams are starting their evaluation.
Three published artifacts now define the agentic-security architecture surface and a buyer should expect every serious vendor to be conversant in all three. The NIST AI Risk Management Framework 1.0 (NIST AI 100-1, January 2023) supplies the four-function governance vocabulary: Govern, Map, Measure, Manage. The Cloud Security Alliance AAGATE specification (December 22, 2025) translates those functions into a Kubernetes-native runtime governance overlay with eight named components and seven continuous control loops, aligned to the CSA AI Controls Matrix (243 controls across 18 domains, July 2025). And MITRE ATLAS v5.1.0 (November 2025) adds the Command and Control tactic (AML.TA0015) and 18 new techniques specifically for AI agents, providing the adversary-model side of the architecture.
Read together, these three artifacts plus ISO/IEC 42001:2023 (the AI Management System standard) define the surface a competent agentic SOC must cover. The reference architecture below is consistent with all four.
The seven layers of the agentic security operations center
Every agentic SOC, regardless of vendor or sector, decomposes into the same seven architectural layers. The names vary in vendor literature; the structure does not. Each layer has its own failure modes, its own integration surface, and its own governance owner. Conflating them, which most legacy security platforms do, is the single largest source of post-deployment risk.
Reference architecture: the seven layers of an agentic security operations center
Each layer has a distinct technical responsibility, a distinct governance owner, and a distinct integration boundary. A vendor that cannot identify the seam between two adjacent layers cannot isolate a failure to one of them.
Why the seven-layer separation matters: A failure at Layer 2 (a model hallucination) requires a different remediation than a failure at Layer 4 (a planning error) or a failure at Layer 7 (a policy gap). Vendors that collapse layers cannot tell you which one failed, which means they cannot help you fix it and your auditor cannot tell which control was bypassed. The architecture is the audit boundary.
Layer 1 and 2: sensing and perception, the foundation everyone gets wrong
The lower two layers are the easiest to evaluate because they are the most testable. They are also where most agentic security claims fail. Layer 1 is the physical signal-capture infrastructure: existing IP cameras, edge appliances, network paths. Layer 2 is the perception layer that converts those signals into structured detections with confidence scores.
The architectural rule at Layer 1 is reusing existing infrastructure rather than rip-and-replacing it. The ONVIF profiles (S for streaming, T for advanced streaming including H.265, M for metadata exchange) are the de facto interoperability standard and any vendor that requires proprietary cameras has imposed a capital cost that is not justifiable by anything that happens above Layer 1. The architectural rule at Layer 2 is that perception must be measurable: confidence scores must be calibrated, false-positive and false-negative rates must be characterized against representative scenes, and the perception layer must be cleanly separable from the reasoning layer that consumes its output. A vendor that conflates Layer 2 with Layer 3 cannot tell you whether a missed detection was a sensor problem or a decision problem.
The privacy architecture is also resolved at this layer. IntelliSee’s platform performs no facial recognition, stores no off-device video, and collects no protected health information. Those are design decisions made at Layer 1/2 that propagate up the stack and that materially change the regulatory exposure of every layer above. A platform that captures biometric data at Layer 1 cannot un-capture it at Layer 7. The privacy posture is set at the bottom of the stack or it is not set at all. This is the same insight that underpins the European Data Protection Board’s repeated guidance on data-minimization-by-design and that is reflected in the ISO/IEC 42001:2023 requirement that AI management systems address data and information governance as a first-class control area, not a downstream consideration.
CAM-12 INTERIOR
Layer 3 and 4: reasoning and orchestration, where the agent actually lives
Layers 3 and 4 are where the system stops resembling a traditional video analytics platform and starts resembling an agent. Layer 3 is reasoning: the decision engine that takes raw perception output and composes it with site context (occupancy, shift, scheduled events, prior incidents, time-of-day, weather, related camera feeds) to produce a classified event with a calibrated confidence score and a recommended response category. Layer 4 is orchestration: the agent runtime that takes the classified event, decomposes a response goal into a sequence of actions, binds those actions to authorized tools, executes them, observes the results, and replans on failure.
This is the layer most directly addressed by the CSA NIST AI RMF Agentic Profile and AAGATE. The profile adds RMF subcategories specifically for agent autonomy, tool-use risk, runtime behavioral governance, and delegation-chain accountability. AAGATE’s Governing-Orchestrator Agent (GOA) and Agent Name Service (ANS) are the concrete instantiations of those subcategories: every agent in the runtime has a verifiable identity, every tool invocation is logged with that identity, and every scope expansion is checked against a policy authored at Layer 7.
The architectural rule at Layer 4 is that agent authority must be bounded in code, not by convention. An agent that “should not” make a particular decision but technically can is governance theater. The bound must be enforceable at the orchestration runtime. The agent literally cannot invoke a tool outside its scope, and the orchestrator literally cannot escalate authority without a Layer 7 approval. AAGATE accomplishes this through Istio mTLS with Cilium eBPF policies; other implementations achieve it through capability-based tokens or signed scope manifests. The mechanism varies. The principle does not: bounded authority, enforced at runtime, with a millisecond containment switch available to the human supervisor.
The “millisecond containment switch” is a real architectural primitive, not a marketing phrase
AAGATE specifies a millisecond containment switch as one of seven continuous control loops in the agentic-AI runtime. The function is concrete: a supervisor can revoke an agent’s tool authority, freeze its action queue, and quarantine its state in less than the time it takes the agent to complete its next action. In a physical-security context, this matters because the action surface includes mass notification, access-control lockdown, and dispatch. Those are actions that, if invoked in error and not containable, generate real-world consequences faster than a human can compose a remediation. A buyer evaluating an agentic SOC platform should demand a demonstration of the containment switch, with timing, on a representative configuration. Vendors who cannot demonstrate it have not built it.
Layer 5: action and integration, where consequences materialize
Layer 5 is the action surface. It is also where most of the integration work and most of the operational risk live. The agent at Layer 4 makes decisions; Layer 5 is where those decisions become irreversible commands to external systems. Mass notification through platforms like Singlewire or AtlasIED. Access-control lockdown through HID, Genetec, or LenelS2 commands. Radio-channel handoff to two-way radio infrastructure. Dispatch to a public-safety answering point through RapidSOS routing or a direct PSAP integration. Camera control via ONVIF Profile T move-and-lock commands.
The architectural rule at Layer 5 is that every action must be reversible at the system layer it touches, even if the real-world consequence is not reversible. Lockdown can be released. Notifications can be retracted. A dispatch can be canceled before responder arrival, even if the page already went out. This is not the same as the action being free of consequences. It is the property that the system can be returned to a known state in the audit log, which is a precondition for the Layer 7 governance review and for any post-incident NIST or DHS SAFETY Act audit.
The integration map a buyer should expect to see, named explicitly in vendor documentation, includes at minimum: ONVIF for camera control, SIP or WebRTC for two-way audio, HID Mercury or equivalent for access control, Singlewire InformaCast or AtlasIED Boomerang for mass notification, RapidSOS or direct CAD-to-CAD for emergency dispatch, and Webhooks or MQTT for the SIEM and ITSM systems that need to receive structured event records. A vendor that names none of these protocols by version has not done the integration work.
Layer 6 and 7: observability and governance, where the audit lives
Layers 6 and 7 are where most agentic deployments fail their first audit. Layer 6 is observability: behavioral telemetry on every agent action, drift detection against a baseline, anomaly scoring, and a lineage record that connects each action backward through the orchestration plan, the reasoning event, and the perception observation that triggered it. Layer 7 is governance: policy authoring, agent identity issuance, scope authorization, and audit-ledger integrity. Together they answer the question every regulator and every plaintiff’s attorney will ask after an incident: why did the system do that, who authorized it, and how do we know the record is unmodified?
The architectural rule at Layer 6 is that observability must capture not just actions but rationales. Logging that “the agent issued a lockdown command” is necessary but not sufficient. The audit-grade record is “the agent issued a lockdown command at T+4.2 seconds in response to a multi-signal corroborated weapon detection at confidence 0.94, under scope-authorization token X issued at T-12 days, with policy version Y, and the action was confirmed received by the access-control system at T+5.1 seconds.” That format (observation, decision, action, outcome, with identity and policy references) is what NIST CSF 2.0’s Govern function expects, what ISO/IEC 42001 audit reviewers ask for, and what survives a post-incident discovery process. The legacy SOAR audit format does not contain it.
The architectural rule at Layer 7 is that policy must be expressed in a form the runtime can enforce, not merely a form a human can read. A policy document that says “the agent must escalate ambiguous events to a human” is governance theater unless the orchestration runtime at Layer 4 actually checks an ambiguity threshold and a routing rule against an enforced manifest. AAGATE’s Policy Translation & Enforcement loop is the canonical implementation: policy authored in human-readable form is compiled into runtime constraints that the agent literally cannot violate. Other implementations use OPA/Rego, Cedar, or capability tokens. Again, the mechanism varies, the principle does not.
The human-in-the-loop checkpoint taxonomy
“Human in the loop” is the most overloaded phrase in agentic AI. The published standards bodies, including ISO/IEC 42105 on AI controllability, distinguish three operational modes, and a competent agentic SOC architecture supports all three at different checkpoints. Conflating them is a frequent procurement failure mode.
Human-in-the-Loop
Human approval is required before the agent acts. The agent prepares a recommendation; the human authorizes execution. Latency is bounded by human availability.
Use at: scope expansion, novel-pattern adjudication, dispatch to external responders during low-confidence events.
Human-on-the-Loop
The agent acts autonomously within a bounded scope; a human supervisor monitors a stream of actions and can intervene, override, or revoke authority. Latency is set by the agent.
Use at: majority-path response — lockdown signaling, camera slewing, paging on high-confidence detection.
Human-in-Command
The system is designed so that final authority, including the authority to set scope, modify policy, and revoke agent identity, never leaves the human role. The agent never authorizes its own scope.
Use at: policy authoring, scope authorization, post-incident review, agent-identity provisioning, kill-switch invocation.
The structural insight is that a competent agentic SOC is HOTL on the majority path, HITL at the boundaries of agent authority, and HIC at the governance layer. A vendor pitch that describes the platform as exclusively HITL is offering an alert-first system with extra steps. A vendor pitch that describes the platform as fully autonomous without naming where HIC is preserved has not addressed the governance question. The taxonomy is also where the EU AI Act’s high-risk-system human-oversight requirements (Article 14) are practically resolved: high-risk systems must be designed such that natural persons can effectively oversee them, which is the operational definition of HOTL plus HIC.
Failure-mode design: drift, scope creep, model regression, and the kill switch
An architecture is incomplete without a failure-mode catalog. Four failure classes recur across every agentic security deployment and the design must address each before the system is operational, not after the first incident.
Behavioral drift. The agent’s action distribution shifts away from the baseline established at deployment. Causes include model updates, environment change (a new entrance opened, a shift schedule changed), or adversarial input designed to gradually move the agent’s perception thresholds. The architectural countermeasure is continuous behavioral telemetry at Layer 6 with drift scoring against the deployment baseline and an automated alert to the supervisor when drift exceeds threshold. This is one of AAGATE’s seven control loops (Behavioral Telemetry Scoring), and it maps to the MITRE ATLAS Reconnaissance and Resource Development tactics, where adversaries explicitly probe for drift opportunities.
Scope creep. The agent’s authority expands, formally or informally, beyond its original deployment manifest. Common cause: a Layer 7 policy change made in haste during an incident, never reviewed, never reverted. Architectural countermeasure: scope changes require a HIC checkpoint with an audit signature, scope expansions are time-bounded by default, and the supervisor console at Layer 6 surfaces “current scope vs. baseline scope” as a first-class metric. AAGATE’s Identity & Provenance Validation loop is the relevant primitive.
Model regression. A model update at Layer 2 or Layer 3 reduces detection quality on a subset of scenes, and the regression is invisible at the orchestration layer because the agent acts on whatever the perception layer reports. Architectural countermeasure: every model deployment runs a shadow evaluation against a representative test corpus, and the regression report is reviewed before the new model is promoted to production. The computer-vision robustness brief covers the test-corpus design in more depth.
Adversarial command-and-control. An attacker compromises the agent runtime or its inputs and uses the agent’s authorized tool surface to pursue an external objective. This is the failure mode that motivated MITRE ATLAS to add the AML.TA0015 Command and Control tactic in November 2025. The architectural countermeasure is layered: zero-trust network policy between agents (mTLS), strict capability tokens, behavioral telemetry that scores agent actions against a baseline, and a millisecond containment switch wired to the supervisor console. Every layer in this list is independently necessary; none is sufficient.
Mapping the architecture to the published controls
A reference architecture is most useful when it can be mapped, control-by-control, to the standards bodies a buyer or auditor will reference. The table below gives that mapping for the seven layers against the four governance frameworks now in production use. A vendor unable to provide an equivalent mapping for their own platform should not be considered for a regulated deployment.
| Layer | NIST AI RMF function | CSA AAGATE component | MITRE ATLAS tactic | ISO/IEC 42001 clause |
|---|---|---|---|---|
| L1 Sensing | Map (data & input) | Edge ingest + ANS | Initial Access defense | 7.5 Resource & data |
| L2 Perception | Measure (model performance) | Inference plane | ML Model Access | 8.4 Performance evaluation |
| L3 Reasoning | Measure (decision quality) | Decision engine + GOA | Defense Evasion | 8.4 / 9.1 monitoring |
| L4 Orchestration | Manage (action & control) | GOA + Istio/Cilium mesh | Command & Control (TA0015) | 8.3 operational planning |
| L5 Action | Manage (response) | Tool/API plane | Impact | 8.3 / 6.2 objectives |
| L6 Observability | Measure (outcomes) | UEBA + Kafka pipeline | Discovery defense | 9.1 monitoring & review |
| L7 Governance | Govern (policy & oversight) | ETHOS Ledger + policy | (out of scope, organizational) | 5 / 6 / 9.3 mgmt review |
Two observations from the mapping deserve emphasis. First, the orchestration layer (L4) is the densest from a control perspective: it appears in every framework and it carries the new MITRE ATLAS Command and Control tactic. This is not a coincidence. Orchestration is where agent authority is exercised, which means orchestration is where adversaries focus and where governance must be most precise. Second, the Govern function in NIST AI RMF and the Clause 5/6/9.3 management-review requirement in ISO 42001 both sit at Layer 7, which means a deployment that has not authored explicit policy and has not scheduled formal management review of the agentic system is non-compliant by definition with both frameworks, regardless of how well the technical layers are built.
The procurement and audit checklist
The reference architecture converts directly into a vendor-evaluation and deployment-audit checklist. Each item is binary: the vendor either meets it or does not. A “we are working on that” answer is a deferred risk acceptance, which the buyer should record explicitly in the procurement file rather than treat as a passing answer.
Layer 1. Does the platform run on existing ONVIF Profile S/T cameras without a hardware refresh? Is there a documented privacy posture (no facial recognition, no off-device video storage) at the sensing layer?
Layer 2. Are confidence scores calibrated on a published test corpus? Are false-positive and false-negative rates characterized for the scene types in the deployment environment?
Layer 3. Is the reasoning layer cleanly separable from the perception layer? Can the vendor produce an event-by-event log that distinguishes a perception miss from a reasoning miss?
Layer 4. Is agent authority bounded in code, not by convention? Demonstrate the containment switch with timing on a representative configuration. Show the orchestration replanning behavior on a simulated tool failure.
Layer 5. Name the integration protocols by version: ONVIF profile, mass-notification platform, access-control vendor, dispatch routing. Demonstrate a reversible action and an audit-grade record of the reversal.
Layer 6. Show an audit-grade event record that includes observation, decision, action, outcome, agent identity, and policy version. Show a drift score against a baseline.
Layer 7. Show the policy artifact as it is authored and as the runtime enforces it. Show the kill-switch mechanism and the role allowed to invoke it. Show the management-review cadence and the most recent review record. Confirm DHS SAFETY Act QATT or equivalent federal liability posture.
Where IntelliSee fits in the seven-layer architecture
IntelliSee’s platform sits across the bottom five layers of the agentic SOC stack. The perception layer (L2) covers active-shooter and gun detection, perimeter intrusion and trespass, and fall, with confidence-scored output and no facial-recognition or biometric capture. The reasoning layer (L3) composes detections with site context. The orchestration layer (L4) executes bounded response playbooks with explicit human-in-the-loop checkpoints at scope boundaries and human-in-command authority preserved at policy and scope authorization. The action layer (L5) integrates with the existing mass-notification, access-control, and dispatch infrastructure through documented protocol surfaces. Observability (L6) is captured in audit-grade event records consistent with the NIST and CSA expectations described above.
The governance layer (L7) is where IntelliSee is differentiated from alert-first competitors. The platform holds DHS SAFETY Act Qualified Anti-Terrorism Technology designation through January 31, 2031, which is a federal liability framework that the alert-first vendor landscape does not have. The privacy posture set at Layer 1 (no facial recognition, no off-device video storage, no PHI) propagates upward through every subsequent layer, which is the architectural reason the platform is deployable in HIPAA-governed healthcare and FERPA-governed education environments where alert-first systems with biometric capture create new risk even as they reduce other risk.
Frequently asked questions
What is the difference between an agentic SOC and a SOAR-augmented SOC?
A SOAR-augmented SOC executes human-authored playbooks against predefined triggers; an agentic SOC includes a runtime that decomposes goals at execution time, plans across tool surfaces, and replans on failure. The architectural difference materializes at Layer 4: orchestration in a SOAR is a static graph; orchestration in an agentic SOC is a dynamic plan bounded by a scope manifest and a millisecond containment switch. The published frameworks (NIST AI RMF, CSA AAGATE, MITRE ATLAS) treat the two as different governance categories, and Gartner and Forrester retired their standalone SOAR evaluations in 2025 in part because the category was being absorbed into agentic SecOps.
How does an agentic security operations center handle human-in-the-loop checkpoints?
Three operational modes coexist in a competent design: HITL (human-in-the-loop) for actions that require pre-execution approval, HOTL (human-on-the-loop) for the autonomous majority path with supervisory monitoring, and HIC (human-in-command) for governance, scope authorization, and the kill-switch role. The architecture must place each checkpoint deliberately. A platform that uses HITL everywhere is alert-first with extra steps; a platform that uses HOTL everywhere has not addressed the governance question.
What protocols connect the layers of an agentic security operations center?
The integration surface a buyer should expect to see named explicitly includes ONVIF Profile S/T/M for camera control and metadata, SIP or WebRTC for two-way audio, HID Mercury or LenelS2 commands for access control, Singlewire InformaCast or AtlasIED Boomerang for mass notification, RapidSOS or direct CAD-to-CAD for emergency dispatch, and Webhooks or MQTT for SIEM and ITSM event delivery. A vendor unable to name these protocols by version has not done the integration work.
How do MITRE ATLAS, NIST AI RMF, and CSA AAGATE relate to each other?
They are complementary. MITRE ATLAS supplies the adversary model with 16 tactics and 84 techniques as of v5.1.0 (November 2025), including the new Command and Control tactic for AI agents. NIST AI RMF 1.0 supplies the four-function governance vocabulary (Govern, Map, Measure, Manage). CSA AAGATE (December 2025) supplies the runtime architecture that translates RMF principles into eight named components and seven continuous control loops. ISO/IEC 42001:2023 supplies the management-system frame around all three. A serious agentic SOC architecture cites all four.
What is the kill switch in an agentic security platform and who owns it?
The kill switch is the millisecond containment primitive that revokes an agent’s tool authority, freezes its action queue, and quarantines its state in less than the time the agent takes to complete its next action. It is a Layer 4 mechanism (orchestration) wired to a Layer 7 authority (governance). The role permitted to invoke it must be a human-in-command role, never an agent role. Buyers should require a live demonstration with timing on a representative configuration; vendors who cannot demonstrate the switch have not implemented it.
Does an agentic SOC require ripping out existing camera infrastructure?
No. The architectural rule at Layer 1 is reuse of existing ONVIF-compatible cameras and edge appliances. A vendor that requires proprietary camera hardware has imposed a capital cost that is not justified by anything that happens above the sensing layer. Most enterprise IP camera infrastructure already speaks ONVIF Profile S; the addition is an edge appliance and the upper layers of the stack.
How is privacy preserved across the seven-layer architecture?
Privacy posture is set at Layer 1 and propagates upward. A platform that performs no facial recognition, stores no off-device video, and collects no protected health information at the sensing layer cannot inadvertently leak that data at higher layers because the data was never captured. This is the data-minimization-by-design principle reflected in ISO/IEC 42001 and in the European Data Protection Board’s guidance, and it is what makes a platform deployable in HIPAA, FERPA, and CCPA-regulated environments without negotiated exceptions.
Continue the architecture research
Three adjacent analyses build on the layers and checkpoints described here. Each links to primary sources cited above and extends the architecture into a different operational dimension.
- Autonomous Security: How Agentic AI Is Replacing Alert-First Architectures — agentic AI
- How Computer Vision Models Handle Occlusion, Low Light, and Adversarial Conditions — technology briefing
- The DHS SAFETY Act in AI Security: Designation, Certification, and What It Actually Means — standards & compliance
For organizations evaluating an agentic security operations center against the seven-layer architecture and the procurement checklist above, a structured conversation with the IntelliSee analysis team is the fastest way to convert framework questions into a documented evaluation. Request a risk assessment to start that review.
