Delegation
On most platforms an automation runs with whatever permissions it was configured with, and an AI agent runs with whatever its API key allows. The human who set it up is long gone from the picture.
RootCX does not work that way. A non-human action is always tied to a human, and it can never do more than that human can. Authority is borrowed, and borrowed authority can only shrink. That is delegation.
The rule
Whenever a principal acts under, or as, another principal's authority, the result is bounded so it can never exceed either side. Power narrows. It never grows. Every mechanism on this page is a different way of holding that line.
A human delegates to an agent
An AI agent has no credentials of its own. It cannot log in, and it holds no standing key. It acts only when a human puts it to work, under that human's authority, in 1 of 2 ways.
Live invocation
A person invokes the agent: clicks run, sends a message. For that run, the agent's authority is the intersection of its own role and the invoker's permissions. It can do only what both sides can do.
Give an admin's agent a read-only role, and it stays read-only. Hand a powerful agent to a read-only user, and it stays read-only. The smaller boundary always wins.
Standing mandate
Some work runs later, with no one watching: a nightly cron, an entity hook, an inbound webhook. Each one carries the identity of the human who created it, recorded as a delegation. Before it fires, the Core revalidates the mandate:
- The delegation is still active.
- The human still exists and is enabled.
- The human still holds the invoke permission.
If any check fails, the automation does not run. Offboard the person who built a nightly job, and the job goes dark the same night. No human behind the action means no action.
A human acts as a service account
A service account is a standing identity for scripts and machines. It acts on its own granted role through its client credentials, like any other principal.
Separately, a human can run an automation as a service account, so the work is owned and attributed to that account instead of to the person. A finance bot's nightly reconciliation should belong to the finance bot, not to whoever happened to schedule it.
This is ownership, not impersonation. There is no "act as anyone" header you can attach to an ordinary request. A human can only assign ownership of automations they create, and only to an identity they are cleared to act as. Acting as yourself is always allowed.
Bounded both ways
The 2 relationships use 2 different guards, and the difference matters:
| Path | Guard | What it means |
|---|---|---|
| Agent invocation | Intersection | The agent gets only the permissions its role and the invoker share. |
| Acting as a service account | Anti-escalation subset | You can only take on an identity whose permissions are a subset of your own. |
Both lead to the same place: you can never gain authority by routing through another principal. Not by invoking an agent, not by borrowing a service account.
Revocation takes effect now
Delegation carries no token and caches nothing. Permissions and grants are resolved live, on every action. Revoke a role, revoke a delegation, or disable the human behind it, and the very next action is denied. There is nothing to wait out and nothing to expire.
Every action traces back
Each delegated action is recorded with who acted, on whose authority, and through what mechanism. During an incident you can answer all 3 at once, for an agent or a service account, from 1 audit trail.
See AI Agent Governance and Service Accounts for the mechanics, and Audit Log for the trail.