{"slug": "six-domains-one-control-plane-mapping-c1-to-sacr-s-armcf", "title": "Six Domains, One Control Plane: Mapping C1 to SACR's ARMCF", "summary": "Software Analyst Cyber Research (SACR) published the AI and Agentic Risk Management and Control Framework (ARMCF) in July, outlining six governance domains—GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER—for managing AI agents as privileged digital actors. C1, a control plane for the agentic enterprise, maps its capabilities to each ARMCF domain, providing identity-based governance across human and non-human identities to operationalize the framework. Principal Industry Analyst Paul Webber stated that C1 secures access across both human and non-human identities, effectively operationalizing the ARMCF.", "body_md": "Most enterprises are shipping AI agents faster than their governance can keep up. The agents book meetings, move data, call APIs, open pull requests, and touch systems that used to require a human and a ticket. The people standing them up rarely think of themselves as provisioning a new privileged account. But that is what they are doing.\n\nThe [AI and Agentic Risk Management and Control Framework (ARMCF)](https://softwareanalyst.substack.com/p/armcf-introducing-a-practitioner), published in July by Software Analyst Cyber Research (SACR), outlines what organizations need to do to manage these new privileged accounts. It takes the six-function lifecycle security teams already know from NIST CSF 2.0 and applies it to systems that can access data, hold identities, invoke tools, and take action on their own. Six domains: GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER. It is built to be operationalized, with control mappings to NIST, ISO 42001, SOC 2, and OWASP behind each domain.\n\n[The framework](https://softwareanalyst.substack.com/p/armcf-introducing-a-practitioner) says it plainly: an agent that can send email, modify files, or call APIs should be governed \"more like a privileged digital actor than like a static software component.\" You govern privileged actors through identity. C1, the control plane for the agentic enterprise, secures access across both human and [non-human identities](/glossary/what-are-non-human-identities/) to help organizations operationalize the ARMCF.\n\n\"The SACR ARMCF framework helps provide governance where agents, that can send email, modify files, or call APIs, are effectively more like a privileged digital actor than a static application. The most effective way to govern privileged actors is through identity. C1, provides such a control plane for the agentic enterprise, securing access across both human and non-human identities and in doing so, operationalize the ARMCF.\"\n\n— Paul Webber, Principal Industry Analyst,\n\nSoftware Analyst Cyber Research\n\nHere is how C1 maps to each domain in the ARMCF.\n\n| Domain | ARMCF asks for | C1 today |\n|---|---|---|\nGOVERN | Named owner per AI system, documented risk acceptance, and a clear RACI for lifecycle decisions. | Ownership on every agent and NHI. Policy engine encodes decision rights. Every grant logs approver and justification. |\nIDENTIFY | A live registry of sanctioned and shadow AI: owner, autonomy level, data sensitivity, blast radius. | Agent and NHI inventory is the live registry. Shadow discovery via connector sweep. Hyperscaler runtimes as identity sources. |\nPROTECT | Agent identity, tool allowlisting, least privilege on data and action-taking, secrets injection. | AIAM gives each agent a real identity. MCP Gateway brokers tool access. Vaulting injects secrets at runtime. |\nDETECT | Behavioral baselines, anomaly detection, and telemetry exported to the SIEM. | Identity telemetry exported to your SIEM. ISPM and Findings track overprivilege and drift. MCP Gateway logs every tool call. |\nRESPOND | Rapid credential revocation, tool-access suspension, agent quarantine, kill switch. | Deprovisioning and findings-triggered automations. Global kill switch in AIAM. Vaulting makes revocation one operation. |\nRECOVER | Re-validate identities, permissions, and allowlists before an agent is redeployed. | Access reviews applied to agents. Permissions re-certified before autonomy returns. |\n\n## GOVERN: accountability you can point to[#](#govern-accountability-you-can-point-to)\n\nARMCF's first domain asks for a named owner on every production AI system, documented risk acceptance, and a clear RACI for who can approve what. Ensuring the policy you build is also a control that can be implemented.\n\nC1 attaches ownership to every agent and non-human identity in the inventory, so accountability is a property of the identity rather than a spreadsheet maintained on the side. The policy engine encodes decision rights directly: who may approve which access, for which agent, under what conditions. Every grant carries its approver and justification, and the record holds up in an audit.\n\n## IDENTIFY: the live registry, including what you didn't sanction[#](#identify-the-live-registry-including-what-you-didnt-sanction)\n\nThe IDENTIFY domain recommends a current registry of sanctioned and shadow AI, each entry tagged with owner, autonomy level, data sensitivity, and [blast radius](/glossary/what-is-blast-radius-in-cybersecurity/). The framework is explicit that the risk lives in the operating environment around the model, not just the model.\n\nC1's agent and [NHI inventory](/solutions/nhi-governance/) is that live registry. C1 finds [shadow AI](/solutions/shadow-ai-discovery/) across endpoint and cloud. Shadow agents surface through a connector sweep across OAuth grants, service accounts, and API keys, so the ones nobody registered still show up. And because the fastest place to catch an agent is where it is born, C1 reads hyperscaler agent runtimes like [AWS AgentCore](/integrations/cloud-providers/aws-bedrock-agentcore/) as identity sources, inventorying agents at the point of creation instead of chasing them after the fact.\n\n## PROTECT: least privilege on access and on action[#](#protect-least-privilege-on-access-and-on-action)\n\nPROTECT is where governance turns into enforced boundaries: agent identity, tool allowlisting, least privilege on both data access and action-taking, and secrets handled so they never sit exposed. For agentic systems, [least privilege](/solutions/least-privilege-access/) has to cover what the agent can do, not only what it can see.\n\nC1 gives every agent a real identity through [AI Access Management](/products/ai-access-management/), with per-user and per-agent authentication, so an agent's reach is scoped and attributable. The [MCP Gateway](/products/ai-access-gateway/) brokers tool access, mediating what an agent is allowed to call. [Vaulting](/solutions/credential-security/) centralizes credentialing and injects secrets at runtime rather than scattering them across scripts and endpoints. All three ensure least privilege for agent access.\n\n## DETECT: telemetry the SecOps team already knows how to read[#](#detect-telemetry-the-secops-team-already-knows-how-to-read)\n\nDETECT calls for behavioral baselines, anomaly detection, and telemetry that flows to the SIEM. ARMCF is deliberate that this belongs in the existing SecOps stack, not a separate console.\n\nC1 emits identity-layer telemetry and exports it to your SIEM of choice. [ISPM and Findings](/solutions/agentic-security-intelligence/) track posture over time, surfacing overprivilege and drift, enriched by signal from CrowdStrike and AWS Access Analyzer. The MCP Gateway logs every brokered tool call, which is the raw material for an agent behavior feed. Baselining and anomaly models run where they belong, in the customer's SIEM and EDR, matching the SecOps-integration model ARMCF prescribes rather than duplicating it.\n\n## RESPOND: revocation as one operation[#](#respond-revocation-as-one-operation)\n\nRESPOND tests whether you can contain an incident without the compromised agent's cooperation: fast credential revocation, tool-access suspension, agent quarantine, a kill switch.\n\nC1 handles containment through deprovisioning and findings-triggered [automations](/products/automations/), plus a global kill switch is available in AI Access Management. For credential revocation, C1 provides the [Agentic Vault](/products/agentic-vault/) to make it a single operation instead of a scavenger hunt. Credentials live in one place under time-bound grants, so cutting an agent off is one action, and the audit trail preserves the evidence a response team needs afterward.\n\n## RECOVER: re-validate before you redeploy[#](#recover-re-validate-before-you-redeploy)\n\nRECOVER addresses safe restoration. Restarting an agent is not recovery. Before it goes back into production, its identities, permissions, and allowlists have to be re-validated.\n\nC1 applies [access reviews](/products/access-reviews/) to agents the same way it does to people, so an agent's permissions get re-certified before its autonomy is restored, and material findings feed back into the next cycle.\n\n## Protect your AI agent deployments with ARMCF and C1[#](#protect-your-ai-agent-deployments-with-armcf-and-c1)\n\nARMCF is a way to report agentic risk to a board that is asking about it, and C1 makes those controls real and measurable across all six domains. It also helps the person with the AI transformation budget, the one racing to enable agent workflows. Governed identity is how you walk into the security review with a solution instead of a problem. The fastest path to shipping agents runs through governing them well from the start. Readiness can be achieved by organizations of all sizes across all levels of AI adoption. It is only limited by your weakest material control, not your average maturity. Identity is the connective tissue that keeps any single domain from becoming that weak point.\n\n**Six domains. One control plane.** Agents are becoming the largest population of privileged actors in the enterprise. ARMCF gives you the lifecycle to manage them. C1 gives you the identity control plane to enforce it.\n\n[Book a demo](/lp/request-demo/) to see how C1 governs agent identity across all six ARMCF domains. For more on where inline enforcement stops and governance begins, read our recap of the SACR session on [why an MCP gateway is not governance](/blog/why-an-mcp-gateway-is-not-governance-webinar-recap/).\n\n*Framework source: SACR, \"ARMCF: Introducing A Practitioner Control Framework for AI and Agentic Risk Management,\" Software Analyst Cyber Research, July 2026.*", "url": "https://wpnews.pro/news/six-domains-one-control-plane-mapping-c1-to-sacr-s-armcf", "canonical_source": "https://www.c1.ai/blog/mapping-c1-to-sacr-armcf", "published_at": "2026-08-24 07:00:00+00:00", "updated_at": "2026-08-24 16:13:00.742266+00:00", "lang": "en", "topics": ["ai-policy", "ai-safety", "ai-agents", "ai-infrastructure"], "entities": ["Software Analyst Cyber Research", "ARMCF", "C1", "Paul Webber", "NIST CSF 2.0", "ISO 42001", "SOC 2", "OWASP"], "alternates": {"html": "https://wpnews.pro/news/six-domains-one-control-plane-mapping-c1-to-sacr-s-armcf", "markdown": "https://wpnews.pro/news/six-domains-one-control-plane-mapping-c1-to-sacr-s-armcf.md", "text": "https://wpnews.pro/news/six-domains-one-control-plane-mapping-c1-to-sacr-s-armcf.txt", "jsonld": "https://wpnews.pro/news/six-domains-one-control-plane-mapping-c1-to-sacr-s-armcf.jsonld"}}