AI agent as a privileged identity, not software

You must establish a named owner for each AI agent with system access, grant it a distinct cryptographic identity separate from human users, enforce minimal rights at runtime rather than at provisioning, and require human approval before any high-impact action. Until you can demonstrate these controls, the agent should not go live.

An analysis of 6 October 2026 of AI agents with access to corporate systems and the governance model they require argues that such agents should be treated as privileged identities rather than ordinary software. The International Association of Privacy Professionals illustrates the case with agents accessing Microsoft 365, GitHub, financial applications and internal databases. In our assessment, this marks a critical shift: existing policy separates "a person with rights" from "software without responsibility", but independent-acting software fits neither category and creates accountability gaps your current controls do not address.

What changes when an agent acts independently?

Once an AI agent makes decisions and executes actions within your systems without human intervention on each occasion, it behaves as an actor with authority, not as a tool. This means you must assess three separate dimensions: authentication (which agent is acting), authorisation (what it may do) and accountability (linking each action to the agent, its human principal, the delegated purpose and the party responsible for monitoring). The risk shifts from "wrong output" to "wrong action with consequences inside your infrastructure".

Which failure modes does independent agency introduce?

• Misuse of delegated rights — an agent exercises permissions beyond its intended scope or for an unintended purpose.
• Scope creep — rights expand unnoticed as the agent is assigned more tasks, enlarging your attack surface.
• Identity spoofing — an attacker impersonates an agent or assumes its identity to execute unauthorised actions.
• Confused-deputy attacks — an agent unintentionally exercises its authority on behalf of another principal or system.
• Accountability gaps — when an agent calls sub-agents or traverses multiple systems, the delegation chain lacks cryptographic provenance, leaving no clear record of who authorised what.

Which concrete controls must you demonstrate before deployment?

1. Assign a named owner — identify a single person or role responsible for the agent's rights, behaviour, incident response and security liability.
2. Issue a distinct cryptographic identity — give the agent its own identity separate from human users or shared service accounts, anchored in cryptography rather than credentials.
3. Enforce minimal rights at runtime — grant only the permissions the agent needs for its specific task, and enforce that scope during execution, not merely at provisioning.
4. Implement short-lived credentials — issue just-in-time access that expires after a defined period, requiring re-authorisation rather than standing permissions.
5. Require human approval for high-impact actions — define which actions (data deletion, configuration changes, financial transactions) require human sign-off before the agent proceeds.
6. Log the delegation chain with cryptographic provenance — record which human principal authorised the agent, what scope was delegated, which sub-agents were called and what each did, with traceability back to a named human decision-maker.

What does liability mean in practice?

Liability for harm caused by an agent may be directed at developers, deployers, monitors and controllers under existing doctrines such as negligence and product liability. The outcome depends partly on factors including foreseeability of the harm, negligence in design or deployment, actual control over the agent's behaviour and the contractual allocation of risk between parties. No court has yet ruled on how liability divides between the organisation that designs the agent, the one that deploys it, the one that operates it and the one that controls it. In our assessment, contractual risk allocation is therefore essential: you should establish in advance an explicit division of security ownership, notification duty and liability in cases of serious harm. Without such agreements, liability may be assessed on the basis of who knew, decided and could have stopped what.

How should you approach approval and ongoing control?

Approve an agent only once you have named its owner, issued it a distinct identity, set an expiry date on elevated access and defined which actions require human approval. Because rights expand unnoticed when an agent is assigned more tasks, set that expiry date per agent and enforce it at runtime. Because accountability gaps arise when delegation chains lack cryptographic provenance, require watertight logging of the chain before the agent goes live. These questions belong in your broader policy around governance for agentic AI. Those who do not answer them in advance discover the answers only after an incident — at the wrong moment, with the wrong party bearing the risk.

Tooling can enforce cryptographic identity, runtime scope and credential expiry. What remains your own professional judgement is the definition of high-impact actions, the choice of owner, the contractual allocation of liability and the decision to approve or refuse deployment. No system can make those choices for you.