By NHI Mgmt Group Editorial TeamBased on C1.ai: “Six Domains, One Control Plane: Mapping C1 to SACR's ARMCF” (August 24, 2026)

TL;DR: C1.ai maps SACR’s ARMCF across GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER to argue that AI agents should be governed as privileged digital actors, with identity providing the control plane for ownership, inventory, tool access, telemetry, revocation, and re-validation. The critical assumption collapse is that static application controls can manage actors that independently hold identities, invoke tools, and take action at runtime.


At a glance

What this is: This analysis maps SACR’s ARMCF to agentic AI governance and concludes that AI agents need one identity control plane across six operational domains.

Why it matters: It matters because IAM, IGA, and PAM teams now have to govern AI agents as privileged actors with inventory, approval, telemetry, revocation, and recertification needs.

👉 Read C1.ai's analysis of agentic AI governance across six domains


Context

AI agents are software entities that can hold identities, call tools, move data, and take actions that used to require a person and a ticket. The governance problem is not the model alone, but the identity and privilege structure around the agent once it starts acting in production.

This article frames that problem through SACR’s ARMCF, which divides operational control into GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER. For identity teams, the key issue is that agentic systems behave like privileged non-human identities with a lifecycle, not static applications with fixed configuration.

The article’s central claim is that identity becomes the control plane for agent governance because ownership, access scope, telemetry, revocation, and re-validation all sit in the identity layer. That makes the topic relevant to NHI governance, PAM oversight, and emerging AI agent controls at the same time.


Key questions

Q: How should security teams govern AI agents that inherit authority from other identities?

A: Security teams should govern AI agents by tracking identity lineage, not just credentials. That means recording the originating identity, the delegated authority path, and the runtime context for each action. If an agent can inherit permissions from humans, services, or other agents, policy has to evaluate the full chain before access is granted or continued.

Q: Why do static application controls fail for autonomous AI agents?

A: Because static controls assume access is stable long enough to be reviewed and changed through ordinary cadence. Autonomous agents can acquire, use, and discard privilege within a single operational cycle, so governance has to move to issuance, runtime policy, and immediate revocation paths.

Q: What are the signs that AI agent governance is too weak for production use?

A: Weak governance usually shows up as poor visibility into what agents can access, incomplete audit trails, and inconsistent oversight across security, legal, compliance, and operations teams. Another warning sign is when organizations cannot explain which datasets an agent used or why it took a specific action. Those gaps make investigation, containment, and compliance far harder.

Q: What should teams check before putting an AI agent into production?

A: Teams should verify three things before production: the agent has a unique identity, its permissions are minimal and explicitly approved, and its actions are fully auditable. They should also confirm that any privacy control used for analytics is layered on top of, not instead of, the access model.


Technical breakdown

Why agent identity becomes the control plane

ARMCF treats an AI agent as a privileged digital actor because the agent can hold access, invoke tools, and affect production systems on its own. In that model, identity is not just login plumbing. It is the mechanism that binds ownership, approval, access scope, and accountability to a specific actor that may be created, changed, or retired faster than a traditional human workflow can track. That is why the framework maps governance decisions to identity records instead of treating the agent as a generic workload. The practical consequence is that every control downstream depends on a live and accurate identity layer.

Practical implication: treat agent identity as the authoritative record for ownership, approval, and access scope, not as an informal inventory entry.

How six-domain lifecycle control differs from static application security

The six-domain model is important because it spans the full lifecycle of an agent rather than only its initial deployment. GOVERN handles ownership and decision rights, IDENTIFY covers inventory and shadow discovery, PROTECT constrains access and tool use, DETECT exports telemetry, RESPOND enables rapid suspension or revocation, and RECOVER requires re-validation before reuse. That sequence mirrors identity governance more than application security because it assumes the actor will persist, change state, and be re-authorised over time. The control plane therefore has to manage both standing permissions and runtime behaviour.

Practical implication: design controls for the full agent lifecycle, including post-deployment monitoring, suspension, and recertification before reuse.

What telemetry and revocation have to prove in agentic AI

For agentic systems, telemetry is only useful if it shows which agent acted, which tool it called, and which permissions were exercised. That makes brokered tool logs, identity-layer telemetry, and SIEM export part of the governance model, not optional observability extras. Revocation has the same standard: response cannot depend on the agent’s cooperation, so credential removal, tool suspension, quarantine, and kill-switch behaviour have to be deterministic and auditable. In practice, the control plane has to prove that access can be cut, actions can be traced, and permissions can be re-certified after an incident.

Practical implication: require tool-call logs, identity telemetry, and deterministic revocation paths before allowing production agent autonomy.


Threat narrative

Attacker objective: The objective is to abuse agent authority so actions appear legitimate while the agent can still access systems, move data, or invoke tools at scale.

  1. Entry occurs when an agent is provisioned with identity, tool access, and runtime permissions that let it act in production rather than in a sandbox.
  2. Escalation happens when the agent’s approved scope expands across email, files, APIs, or other systems without equivalent governance updates.
  3. Impact follows when the agent can keep operating, calling tools, or retaining permissions without rapid suspension, re-validation, or quarantine.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Identity is the control plane because agent governance is fundamentally about privileged actor management. Once an AI system can hold identity, call tools, and change state on its own, the governance problem shifts from software configuration to access governance. ARMCF is useful precisely because it turns lifecycle control into an identity discipline, not a model-management exercise. Practitioners should stop treating agent access as a by-product of deployment and start treating it as the main control surface.

Static application controls were designed for software that does not independently create governance events. That assumption fails when an agent can obtain access, use it, and outpace review cycles inside its own runtime. The implication is not merely that more controls are needed. It is that recertification, approval, and revocation have to move to issuance time and runtime state, because the old assumption of stable privilege no longer holds.

Agent discovery and shadow inventory now belong in the same operational conversation as NHI governance. The article’s IDENTIFY domain reflects a broader market shift: agents are becoming another class of governed non-human identity, not a side feature of AI platforms. That means inventory completeness, ownership, and autonomy level are now board-level controls. Practitioners should merge AI inventory with NHI inventory instead of building separate silos.

Detection without identity attribution will not be enough for agentic systems. The control question is no longer only whether anomalous activity occurred, but which agent performed it, which permissions enabled it, and whether those permissions were still valid. That ties SIEM, broker logs, and identity telemetry together. Practitioners should evaluate whether their detection stack can support agent-level accountability before expanding production autonomy.

Recoverability must include permission re-validation, not just service restart. ARMCF’s RECOVER domain highlights a failure mode many programmes miss: an agent can be technically restored while its access remains unsafe. Re-certification before redeployment is therefore a governance requirement, not a paperwork step. Practitioners should make re-validation a mandatory gate before any agent returns to production.

From our research library:

What this signals

Governance programmes that treat agents as ordinary automation will miss the real control point. ARMCF’s six-domain structure is a reminder that agent risk spans ownership, inventory, access, telemetry, response, and reuse. The practical shift is to unify AI agent oversight with NHI governance so the same identity controls govern both human-delegated and machine-executed actions.

Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey. That gap means many teams are scaling agent autonomy before they have lifecycle controls that can survive audit, incident response, or board scrutiny.

Agent ownership debt: a production agent without a named owner, scoped permissions, and re-certification cadence becomes a standing governance exception. Practitioners should watch for that debt accumulating first in shadow discovery, then in overbroad tool access, and finally in response plans that cannot name the actor being contained.


For practitioners

  • Define a named owner for every production AI agent Record the approver, risk owner, and scope for each agent so accountability is tied to the identity record rather than a separate spreadsheet.
  • Build a live agent and NHI inventory Track sanctioned and shadow agents with autonomy level, data sensitivity, and blast radius so discovery is continuous, not periodic.
  • Constrain tool access through identity-bound policy Require per-agent authentication, tool allowlisting, and least privilege on both data access and action-taking before production use.
  • Export identity telemetry into the SIEM Log every brokered tool call, preserve approver context, and feed identity-layer telemetry into existing detection and investigation workflows.
  • Require re-certification before redeployment Make permissions review, allowlist validation, and ownership confirmation mandatory before an agent is returned to autonomous operation.

Key takeaways

  • AI agents now behave like privileged digital actors, so the governance problem is identity, access, and accountability rather than model quality alone.
  • The article’s six-domain mapping shows that inventory, detection, response, and recovery all depend on a live identity control plane for agents.
  • Practitioners should unify agent oversight with NHI governance so ownership, tool access, telemetry, and re-validation are controlled in one lifecycle.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0 and NIST AI RMF set the technical controls, and SOC 2 (AICPA) defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI03 — Identity & Privilege AbuseThe article centres on privileged agent governance and scope control.
Recommendation — Apply ASI03 to bind agent actions to identity, scope, and approval boundaries.
OWASP Non-Human Identity Top 10NHI-05 — Overprivileged NHIThe article treats agents as privileged non-human identities with scoped access.
NHI-01 — Improper OffboardingRevocation, quarantine, and recovery depend on reliable agent offboarding.
Recommendation — Reduce overprivileged agent access and align permissions to current task scope. Ensure agent deprovisioning removes access, credentials, and tool reach immediately.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article maps agent governance to access grants, approvals, and entitlement control.
Recommendation — Use PR.AA-05 to govern agent entitlements and review them before autonomy expands.
NIST AI RMFGOVERN — AI Governance and AccountabilityARMCF governance maps directly to AI governance, ownership, and accountability.
Recommendation — Establish governing bodies and decision rights for each production AI agent.
SOC 2 (AICPA)CC6.1 — Logical Access Security Software and InfrastructureThe article discusses access control, approvals, and revocation for AI agents in production.
Recommendation — Document and enforce logical access controls for agents within your assurance program.

Key terms

  • Agentic AI Identity: The complete set of credentials, permissions, and governance controls applied to an autonomous AI agent, covering authentication, authorisation, action logging, and access revocation. Distinct from traditional NHI because agent identities are often ephemeral, delegated, and multi-hop.
  • Identity Control Plane: An identity control plane is the governance layer that decides who or what can access systems and under what conditions. In practice, it coordinates authentication, authorization, privilege review, and lifecycle management across human and machine identities so access policy is enforced consistently across environments.
  • Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
  • Agent re-certification: Agent re-certification is the act of re-checking an AI agent’s permissions, ownership, and allowlists before it is allowed back into production. It is the agentic equivalent of lifecycle review, but it must happen at the point of redeployment because access can change quickly.

What's in the full article

C1.ai's full blog covers the operational detail this post intentionally leaves for the source:

  • Domain-by-domain mapping from SACR’s ARMCF to governance, identify, protect, detect, respond, and recover controls
  • Examples of identity-layer enforcement for AI Access Management, MCP gateway logging, and agent kill-switch handling
  • The article’s exact control language for ownership, approval records, and re-validation before redeployment
  • How C1 positions identity telemetry, posture findings, and access reviews inside the agent lifecycle

👉 The full C1.ai post covers the ARMCF mapping, identity control plane, and lifecycle controls in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 25, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org