Treat an AI agent with system access as a privileged identity, not as software

An AI agent that accesses corporate systems, calls APIs or changes configurations should be governed as a privileged identity, not as ordinary software. That means its own identity, minimal rights, short-lived access, continuous monitoring, human approval for high-impact actions and a predefined owner for security and liability.

What does the IAPP establish about AI agents with access to corporate systems?

In an editorial contribution of 5 October 2026, the International Association of Privacy Professionals (IAPP) points out that AI agents given access to systems such as Microsoft 365, GitHub, financial applications, internal databases and APIs raise new questions about cybersecurity, identity and liability. The core: as soon as an agent carries out actions independently, it behaves not like a tool but like an actor with authority. It is an opinion contribution, not an official finding, but the analysis aligns with recent government guidance.

The IAPP contribution thereby makes explicit a governance shift that many organisations have not yet reflected in their policy. In our assessment this is the most important point: the existing separation between "a person with rights" and "software without its own responsibility" does not adequately account for software that makes decisions independently within your systems.

Why is ordinary software security not enough for an acting AI agent?

For an acting agent you must be able to assess authentication, authorisation and accountability separately: authentication establishes which agent is acting; authorisation determines what it may do; accountability links each action to the agent, its human or organisational principal, the delegated purpose and the party responsible for monitoring and intervening.

The joint guidance from six national cybersecurity agencies — the Australian ACSC, the American CISA and NSA, the Canadian Centre for Cyber Security and the NCSCs of New Zealand and the United Kingdom — names concrete risks: misuse of rights, scope creep (rights that expand unnoticed), identity spoofing, confused-deputy attacks (where an agent unintentionally exercises its authority on behalf of another) and accountability gaps. The recommended measures are set out in Careful adoption of agentic AI services: a separate, cryptographically anchored identity per agent, minimal rights, runtime authentication, short-lived (just-in-time) credentials, continuous monitoring and human approval for high-impact actions.

In a February 2026 concept paper, the NIST National Cybersecurity Center of Excellence identifies questions around distinguishing agents from human users, scoping delegated permissions, linking agent actions to a named principal and preserving accountability. This supports our assessment that shared or generic service accounts can create attribution gaps for acting agents. An academic study on arXiv adds that identity alone is not enough: as soon as agents call sub-agents or traverse multiple systems, an accountability gap arises if the delegation chain lacks cryptographic provenance and enforceable scope. This underlines the importance of giving an agent its own identity with delegated and logged authorisation and of enforcing least privilege during execution, not at provisioning.

Who is liable if an AI agent causes harm?

That is not yet settled in law. Paul Ohm, professor at Georgetown University Law Center, explained on 30 September 2026 in testimony before a subcommittee of the U.S. Senate that injured parties can direct claims at developers, deployers, monitors and controllers, along existing doctrines such as negligence and product liability. He also discussed possible new legislation with liability for developers and deployers in cases of serious harm.

Important for the level-headed reader: these are proposals and legal arguments, not adopted rules or court rulings. The hearing has not changed the law. What the testimony does make clear is that the chain of liability in the developer-deployer chain may in future be examined on the basis of who knew, decided and could stop what. The sources leave one question open: how that liability is divided in practice between the parties that design, deploy, operate and control the agent. In our analysis, contractual risk allocation is therefore important, but in the absence of agreements the liability question may be assessed partly by factors such as the foreseeability of the harm, negligence, actual control and applicable contractual provisions; the outcome is not fixed in advance.

What does this mean for directors, lawyers and CISOs who must approve an agent?

Our analysis: because an agent with system access can carry out actions independently, the risk shifts from "wrong output" to "wrong action with consequences"; therefore organisations should approve an agent only once a named owner is responsible for its rights, behaviour and incident handling. Because rights expand unnoticed when an agent is given more and more tasks, scope creep arises that enlarges your attack surface; therefore you set an expiry date on elevated access per agent and have it enforced at runtime rather than at issuance. Because an accountability gap can arise when an agent calls sub-agents and the delegation chain lacks cryptographic provenance and enforceable scope, you require watertight logging of the delegation chain before the agent goes live, with traceability to a human principal. Our analysis: because the liability outcome depends partly on contracts, foreseeability, negligence and actual control, the lawyer must set out in advance an explicit division of security ownership, notification duty and liability in cases of serious harm.

As a summary, you should approve an agent only once you can answer the following points:

• Who is the named owner of this agent within your organisation?
• Which data and which tools can it reach, and with what minimal rights?
• Which purpose authorises each action, and when does elevated access expire?
• Which independent control can stop it during high-impact or irreversible actions?
• Which logs preserve the delegation chain up to a human principal?
• Which organisation investigates and notifies after harm, and is that set down contractually?

These questions belong in your broader policy around governance for agentic AI and AI agents. 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.

Sources: The article draws on the IAPP contribution, the joint guidance from six national cybersecurity agencies, the NIST concept paper on agent identity, Paul Ohm's Senate testimony and an arXiv study on AI identity.