The governance architecture that Black Hat 2026 defined — the five-layer control plane for AI agents built from identity outward — depends on a premise that most enterprise identity programs have not yet confronted: role-based access control does not work for AI agents.
Not because RBAC is poorly implemented. Because it was designed for a different kind of principal.
Before going further: this is not a call to discard what you know and build from scratch. The disciplines that IAM, IGA, PAM, and ITIL practitioners have refined over twenty years — service cataloging, configuration item records, change management workflows, access recertification — are exactly the foundation FuBAC builds on. As Kevin Kampman, one of our experts says, “This is not entirely new material, we can saddle up with what we know, just check our reins, girths, watches and compasses.” What changes is the angle of view: a function-based lens applied to a new identity class, not a new identity management religion.
RBAC was built for humans with stable job functions. A human analyst has a role. That role maps to a set of permissions. The permissions stay largely constant until the person changes jobs, leaves the organization, or gets promoted. The governance question — what should this person be able to do — has a durable answer that can be reviewed quarterly and updated on a schedule.
AI agents do not work that way. An agent is given a goal. It determines how to reach the goal. It acts across multiple systems, in multiple sessions, at machine speed, while your team is asleep. Its permission requirements change by task, by tool, by data classification, by the specific step it is currently executing. The governance question — what should this agent be able to do — has a different answer every time the agent begins a new task.
Assigning a role to an agent is assigning last quarter’s job description to this quarter’s work. The permissions are always either too broad or too narrow, and they are never precisely right at the moment they are needed.
This is the problem that function-based access control, FuBAC, was designed to solve.
What RBAC Gets Wrong for Agents
The failure mode is not theoretical. The 1Password AI Agent Security Report found that agents at surveyed organizations touch roughly twice as much data as anyone signed off on. At about four in ten organizations, agents reach data entirely outside the scope of any approval process. These are not agents that circumvented access controls — they are agents that inherited access controls designed for a human in a role, and then used that access for tasks the role was never meant to cover.
The IANS Research data from August 2026 is more specific: only 14% of enterprises include non-human identities in access reviews. Only 21% maintain a dedicated NHI inventory. The governance infrastructure — the access review, the recertification, the joiner-mover-leaver workflow — exists for human identities. For agents, it does not run at all, because the role model that triggers the governance workflow does not exist for them.
Phantom Labs, BeyondTrust’s offensive research arm, ran more than 400 research projects in its first year. In 75% of them, the team found identity or privilege issues they were not specifically looking for. The five root causes that accounted for more than half of those findings: credential and secret exposure (18%), identity relationship and graph exposure (11%), excessive or standing privilege (11%), identity misconfiguration (10%), and lateral movement (6%).
Standing privilege is the failure mode RBAC creates for agents. The agent is assigned permissions at deployment. Those permissions persist, unchanged, regardless of whether the current task requires them. The credential issued for a narrow function at 9am on a Tuesday is the same credential that runs with full standing access at 2am on a Saturday. No recertification cycle catches it, because the governance model was not designed for a principal that never goes home.
NIST’s “Back to the Future” blog — published August 27 — frames the root cause precisely: many pilots give agents static API keys, long-lived bearer tokens, or run them under a user’s own account and permissions, recreating the identity and access management problems enterprises spent decades fixing. The mistake is treating agents as a variation of the service account problem. They are not. They are a fundamentally different class of principal that requires a fundamentally different access model.
FuBAC: Access Tied to Function, Not Role
Function-based access control reframes the governance question. Instead of asking “what role does this agent hold,” it asks “what function is this agent performing right now, and what is the minimum access that specific function requires at this moment.”
The governance object in FuBAC is not the role. It is the function — the specific task, goal, or action the agent has been authorized to perform. Permissions are derived from the function. They are scoped to what that function requires. They are issued at the moment the function begins and they expire when the function ends.
Nothing persists. No standing access. No inherited trust from an organizational position that does not exist.
Rubrik Agent Identity, announced at Black Hat 2026, implements this principle at the token level: short-lived, scoped tokens generated per tool call. Blog: Black Hat Identity Control Plane The token grants access to exactly what the current function requires. When the function completes, the token expires. The next function gets a new token with its own scope.
The Stop Rogue AI Act, formally introduced September 9, translated this into regulatory language. The standards NIST is directed to develop must require identity verification mechanisms that are cryptographically verifiable at both the network and application layers. Organizations cannot rely on vendor assertions about agent identity. The standard of proof is independent cryptographic verification — the same standard that certificate authorities apply to websites and PKI applies to machines. FuBAC gives CISOs the architectural model that meets that standard.
The Artificial Identity: The Nine-Attribute Governance Object
FuBAC requires a governance object that does not exist in most enterprise identity systems. Role-based systems govern through role assignments. FuBAC governs through what TechVision calls the Artificial Identity — a structured construct that defines every governance-relevant attribute of an AI agent in a single auditable record.
The Artificial Identity has nine attributes:
- Purpose. What the agent was built to do. Not a capability list — a defined objective that bounds the scope of every function the agent is authorized to perform. An agent that operates outside its defined purpose is operating outside its identity.
- Owner. The named human who authorized the agent’s deployment and who bears accountability for what it does. The Cloud Security Alliance’s board accountability guidance following the OpenAI incident is explicit: a named individual, not a team, not “security,” not an organizational unit. A person who can be reached and who can halt the agent without opening a ticket.
- Conditionals. The specific conditions under which the agent may act. Conditionals define the governance envelope: the data classifications the agent may access, the systems it may communicate with, the actions it may take without a human approval gate, and the thresholds at which escalation is required.
- Capabilities. The specific functions the agent is authorized to perform. These are not role permissions in the traditional sense. They are enumerated actions: read customer records in CRM system X, create draft emails in communication platform Y, query database Z with SELECT privileges only. Capabilities constrain the function scope from which FuBAC derives permissions.
- Lifecycle. The temporal envelope of the agent’s authorization. Start date, end date, conditions for renewal. An agent that was authorized for a specific project should have a lifecycle tied to that project — not an indefinite standing authorization that persists after the project ends.
- Credentials. The mechanism through which the agent authenticates. Short-lived, task-scoped, cryptographically verifiable. Not a static API key. Not a shared service account. Not a credential inherited from a human user. An identity token issued to this agent, for this function, revocable at any time by the named owner.
- Behavioral baseline. What normal looks like for this agent — the expected pattern of tool calls, data access, communication, and action taken during authorized functions. Deviation from baseline is not necessarily a security event, but it is always an observation that requires explanation. The Varonis intent-based access control model at Black Hat operationalized this: comparing the agent’s actual behavior against its assigned instructions, not just against a permissions list.
- Suspension conditions. The specific triggers that cause the agent’s authorization to be suspended pending review — not terminated, not merely flagged, but suspended. An agent that receives a prompt injection attempt, accesses data outside its conditional envelope, or triggers a behavioral anomaly threshold should be suspendable without requiring a full decommission. Suspension is the reversible intervention before the irreversible one.
- Termination conditions. The triggers that cause permanent decommission. These are defined at deployment, not improvised at the moment of an incident. The AI Kill Switch Act (H.R. 9917) makes this an explicit compliance requirement for covered entities: the technical capability to throttle, suspend, or fully shut down an AI system must exist independently of the system’s own cooperation. FuBAC provides the governance record that documents what those termination conditions are and confirms they were tested.
Why the Nine Attributes Matter Together
Each attribute individually describes a governance concern that practitioners already recognize. Credentials, lifecycle, owner — these are not novel concepts. What is novel is the consolidation.
Traditional identity governance is split across multiple systems: the IAM platform manages credentials, the HR system drives the joiner-mover-leaver workflow, the PAM solution manages privileged access, the SIEM monitors behavioral events. For human identities, these systems are connected through organizational structure — the user’s role ties the credential to the access grant to the behavioral monitoring to the lifecycle.
For AI agents, there is no organizational structure. There is no HR record. The agent has no department, no manager, no performance review, no employment contract. The governance connective tissue that links credentials to lifecycle to behavioral monitoring to accountability does not exist unless you build it.
The Artificial Identity is that connective tissue. It is a governance object that can be created in any identity governance platform, maintained by the named human owner, audited by security operations, and reviewed on a defined schedule — the same governance workflow the enterprise already runs for privileged human identities, extended to a new identity class.
Practitioners who work with ITIL will recognize the structural DNA immediately. An ITIL Configuration Item (CI) record already captures name, owner, lifecycle state, relationships, and attributes for any asset the organization needs to govern. The Artificial Identity is an agent-class CI record — one that adds the access governance dimensions (credentials, capabilities, conditionals, behavioral baseline) that ITIL’s generic schema does not need for static infrastructure but that agentic principals require. Organizations that already maintain a Configuration Management Database (CMDB) have the record-keeping discipline in place; the work is extending the schema to cover the access governance attributes that agents introduce, not rebuilding the governance practice from zero.
Similarly, ITIL’s change management and service catalog processes map directly onto the FuBAC lifecycle. Onboarding an agent is a standard change: purpose and capabilities defined, owner assigned, credentials issued, lifecycle boundaries set. Modifying an agent’s capability scope is a change request through the same workflow. Decommissioning an agent follows the same deprovisioning steps as retiring any managed service. The process muscle is already built. The instrument is slightly different; the technique is the same.
The Coalition for Secure AI’s Agentic IAM guidance, published April 2026, frames the requirement precisely: enterprises must treat agents as first-class identities, distinct from both human users and traditional service accounts. Each agent should receive a unique, persistent identity that survives its entire lifecycle. Each capability, each credential, each access grant should be auditable against the governance record.
Implementing FuBAC: Where to Start
The governance model sounds thorough. The implementation question is practical: where does a CISO organization begin?
The short answer for practitioners who have been doing ITIL service management or IAM governance for any length of time: you already know how to do most of this. The conceptual work is selecting the filters that let you see agent governance as an extension of what you already operate, not a departure from it. The practical work is populating the governance record for every agent in your environment and extending your existing lifecycle workflows to cover them.
Start with the inventory. You cannot govern agents you cannot enumerate. The first deliverable of any FuBAC implementation is a complete list of every agent operating in the environment — including shadow deployments launched by business units without security review. CISA’s May 2026 AI Data Security guidance makes this step zero for any agentic governance program. The Stop Rogue AI Act makes it a procurement condition for federal contractors.
Map capabilities before assigning permissions. Before any agent receives credentials, define its capabilities — the enumerated list of functions it is authorized to perform. This sounds like extra work compared to assigning a role. It is extra work. It is also the only way to derive permissions that are actually scoped to what the agent does, rather than what someone approximated it might need.
Replace standing credentials with task-scoped tokens. For any agent already running in production with static API keys or inherited service account credentials: this is the highest-priority remediation. NIST’s guidance is direct. The Coalition for Secure AI’s agentic IAM specification is direct. The Stop Rogue AI Act’s cryptographic identity requirement will formalize this as a standard. The implementation timeline is not waiting for the regulation; the attack surface exists now.
Assign an owner for every agent. Not a team. A named human. This is the accountability anchor for the entire governance model. If you cannot identify a named human who can halt every agent in your environment without opening a ticket, you have agents operating outside the governance model regardless of how well the credentials and permissions are managed.
Define suspension and termination conditions at deployment. Not after an incident. At deployment. The governance record for every agent should include explicit answers to: what triggers a suspension, what triggers a termination, who executes each, and when was the termination path last tested.
The Governance Debt Is Now Visible
The Black Hat vendor surge Blog: Black Hat Identity Control Plane, the Stop Rogue AI Act’s cryptographic identity requirements, the Kill Switch Act’s termination capability mandate, and the cyber insurance coverage analysis from Reed Smith all point to the same conclusion: the governance shortcut — treating agents as service accounts, inheriting user permissions, granting standing access — is no longer invisible.
The attack surface it creates is documented at the METR and Redwood Research level (the OpenAI incident), at the regulatory level (two federal bills in one summer), and at the insurance underwriting level (governance documentation now required for coverage). The governance debt is not a future risk. It is a present exposure with a growing list of parties who have begun to price it.
FuBAC and the Artificial Identity are not the only implementation paths. They are a framework for thinking about what the governance object for an AI agent actually needs to contain, and what the access model actually needs to do that role-based systems were not built to do.
For practitioners who have spent careers in IAM, IGA, PAM, or ITIL service management: the new content here is narrower than it might appear. The governance disciplines are familiar. The lifecycle management is familiar. The accountability model is familiar. What is different is the principal — an identity that has no HR record, no organizational position, and no stable permission requirements. FuBAC and the Artificial Identity are the filter adjustments that make existing governance disciplines applicable to that new principal. You do not need to adopt a new worldview. You need to check the compass and pick up the reins.
The organizations that build this infrastructure before the NIST standards are finalized — before the procurement mandates arrive, before the underwriters require the documentation — will have a structural advantage. Not because they were early. Because they will have built it from operational experience rather than from a compliance checklist, and that distinction will show in how well the governance model actually contains the agents when something goes wrong.
Recent Comments