A role is not a capability

A role is not permission for an AI agent to act. Production AI needs a named capability before every side effect — not “the agent has the admin role.”

Roles are how most organizations hand out access. Someone maps a group to a set of systems, the agent’s identity gets added to that group, and from then on it can reach whatever the role reaches. That is useful for provisioning and for keeping humans out of systems they should never see. It is not a capability record on a mounted Knowledge Image. When counsel or an owner asks why the system closed a live claim at 02:14, “the agent was in the adjusters group” is not a receipt. The role explained what the agent could reach. It did not decide whether this run was authorized to take that action, on that record, from that knowledge.

Hive Forensics AI builds for buyers who need the opposite: workflows where production action is gated by a named capability on a mounted, hashable corpus. You can keep role-based access exactly where it belongs. Membership is not the capability. Being in a group does not create authority for an agent on the live Knowledge Image.

What a role actually is

A role is a standing grant attached to an identity. It answers “which systems can this account reach, in general, until someone removes it?” It does not answer “was this agent allowed to make this change, with this tool, from this version of the knowledge, right now?”

A control decides whether an action may happen, with which tool, on which knowledge, under which conditions. You can say which capability record was live, which Knowledge Image was mounted, whether the target was in scope, and whether the run was allowed to act before the effect. If access must change, you revoke the capability — you do not wait for a quarterly access review to notice the agent still holds a role it inherited from a pilot. Reach is not authorization.

Why buyers mix them up

Vendors sell “enterprise-ready agents” because “it plugs into your existing roles.” Demos look serious when the agent shows up in the directory with the right group badge. Operators hear “it only has the permissions the role allows” and stop asking which action was actually granted for which workflow. When SIU, fraud review, or a security owner asks why the system updated that account because the role happened to include write access, “it was within its role” is not an answer you can replay against the live run. A role is an identity property. Authorization is a capability property. Safety-by-membership is still action-first the moment the role is broad enough.

How Hive Forensics AI ships the boundary

You need a portable unit of knowledge — a Knowledge Image you can hash, pin, and mount — plus a runtime that fails closed when the capability record is missing, stale, or revoked. Roles stay where identity and reach belong. Each production side effect must pass its own capability check. A generous role does not expand what the agent may do in live.

That is the work Hive Forensics AI ships: verifiable knowledge, receipts, and default-deny where the workflow demands them. Work starts on a five-day Bootcamp: one corpus, one workflow, representative source material, and a Friday recommendation with an evidence path. If the capability boundary holds, a bounded deploy can follow. If it does not, you learn that early, on purpose.

If your workflow cannot afford an action justified only by “the agent had the role,” start there.

Start a HIVE Bootcamp or send an engineering brief