Estimated reading time: 5 minutes · Last updated:
AI agents—software that can call APIs, execute code or change configurations—create a new privileged-user attack surface that can be exploited far faster than a human-driven intrusion. Brian Hengesbaugh, global chair for data and cyber at Baker McKenzie, argues organisations must inventory agents, map what each can access and define what they may do without human approval, as first reported by IAPP. The practical implication is that security teams and legal counsel need automated monitoring and containment controls because manual approvals will often be too slow to stop rapid, automated misuse.
An agent that can access Microsoft 365, GitHub, a financial system or an internal database effectively has an identity. If it can call an API, execute code or modify a configuration, it has privileges and authority that need to be managed just like any other privileged identity.
Forbes
Key takeaways
- Forbes highlighted that an AI agent with access to Microsoft 365, GitHub or an internal database should be treated as a privileged identity.
- Brian Hengesbaugh of Baker McKenzie urges organisations to inventory agents, map their access, define authorities and ensure activities are logged.
- Hengesbaugh notes that AI agents have no privacy rights, allowing employers to monitor agent activity without privacy notices or works council consultations.
- A compromised agent could be repurposed to target partner systems, producing an AI-enabled supply-chain compromise, the author warned.
Table of contents
Treat an AI agent as a privileged identity and inventory it
Security teams must recognise an AI agent as a privileged identity when it can access Microsoft 365, GitHub, financial systems or internal databases. The concept is simple: if an agent can call an API, execute code or modify a configuration, it holds authority that attackers can exploit. Firms should maintain a live inventory that records who owns each agent, what credentials it uses and which systems it can reach.
Maintaining that inventory is an operational task that crosses security, development and legal teams. Inventory should include agent provenance (who created or supplied it), the scope of its credentials and any external integrations where the agent exchanges files or messages. That record is the baseline for access reviews, role-based restrictions and for drafting contractual limits with third-party providers and partners.
Operational ownership matters because an inventory without enforcement is of limited value. Privileged access management, least-privilege role definitions and just-in-time credentialing all follow from knowing which agent is active and what it can do. The keyPhrase privileged identity should be the lens CISOs use when deciding whether an agent needs real-time controls or only light oversight.
Speed forces automation: monitoring, revocation and containment
Because AI agents can act at machine speed, security teams should design detection and response around automated workflows rather than human approvals. Brian Hengesbaugh argues that traditional human checkpoints will often be too slow to interrupt an attack progression that uses an agent to escalate privileges or move laterally. Automated responses can include session revocation, credential rotation and network segmentation triggers tied to anomalous agent activity.
Automated controls carry their own risks, such as false positives that cause business interruption; managing that trade-off requires clear rules of engagement and testing in staging environments. Where an agent touches partner systems, automated containment should include blocking outbound file exchanges or quarantining messages to prevent an AI-enabled supply-chain compromise from propagating. Designing those rules demands input from security, legal and operations so containment actions are proportionate to business impact.
Monitoring must be continuous and sufficiently granular to show what an agent did, when and under which account context. That audit trail is essential both for forensic response and for demonstrating compliance if regulators or counterparties ask how the company governed its agents. The section emphasises that technical telemetry and playbooks must be in place before an incident occurs to avoid chaotic, manual decision-making under pressure.
Legal exposure, privacy and the weaponisation risk
From a legal standpoint, companies face the same spectrum of consequences as with other cyber incidents: business interruption, notification obligations, regulatory action and privacy litigation. Hengesbaugh points out a defensive legal angle: if AI regulation establishes standards of care and a company can show it met those standards, regulation may create a measurable defence against negligence claims. That dynamic makes it practical for counsel to map security controls to any applicable AI governance rules.
Crucially, Hengesbaugh highlights that AI agents have no privacy rights, so organisations can monitor agent actions without the consent and consultation steps required for human employees. That removes a common procedural hurdle but does not eliminate other legal obligations—such as breach notification where personal data is exposed—or contract-based indemnities with partners. Companies must therefore align monitoring practices with incident response and disclosure frameworks.
The wild card is weaponised agents used to attack others: a compromised agent could inject malware or malicious links into files exchanged with partners, escalating impact beyond the initial breach. Legal liability in that scenario will turn on foreseeability, contractual limits and indemnities; documenting agent governance and incident playbooks will matter in any subsequent claims or regulator inquiries. The section ties technical controls to legal posture and third-party risk management.
| Risk vector | What it affects | Control examples | Owner |
|---|---|---|---|
| Agent credential compromise | Microsoft 365, GitHub, internal APIs | Just-in-time creds, rotation, PAM | Security |
| Unauthorized agent actions | Configurations, deployments | Authority reviews, action whitelists | DevOps + Security |
| Agent-mediated supply-chain attacks | Partners and shared files | File scanning, exchange quarantines | Security + Legal |
How this evolves
The case for
- Clearer AI regulation could set standards of care that companies map controls to, reducing litigation risk if companies comply.
- Tooling vendors will increasingly offer agent-aware PAM and telemetry features that make inventory and automated containment easier to operationalise.
The case against
- Attackers will adapt to agent controls, leading to faster, more automated exploitation chains and higher blast radii for breaches.
- Fragmented regulation across jurisdictions could leave companies exposed to differing compliance obligations and cross-border notification duties.
What to be careful about
- Rapid escalation: an agent that can execute code may enable privilege escalation and lateral movement much faster than human-driven attacks.
- Supply-chain amplification: a compromised agent can become a pivot to infect partners through routine file exchanges.
- Regulatory and contractual liability: notification obligations, class actions and indemnity clauses can multiply financial and reputational impact.
- Operational disruption from automated containment: false positives in automated revocation could interrupt critical business functions.
The bottom line
AI agents change the calculus of privileged access by combining reach and actionability with machine speed. That shift means security and legal teams must work together to document which agents exist, what each can access, what they may do without human sign-off, and how their activity is monitored and contained. Mapping controls to any applicable AI governance standards gives firms both a technical defence and a legal posture they can point to after an incident. Preparing inventory, automated containment playbooks and integrated incident-response plans now reduces both operational disruption and downstream liability.
What to watch
- Watch for national or sectoral guidance that defines minimum security controls for AI agents; no date has been set.
- Watch for public breach reports that identify an AI agent as the initial access vector; no date has been set.
Frequently asked questions
What makes an AI agent a privileged risk?
An AI agent becomes privileged when it can access systems such as Microsoft 365 or GitHub, call APIs, execute code or change configurations. That combination of access and actionability means attackers who control the agent can escalate privileges and move laterally quickly.
Can companies monitor AI agent activity without employee privacy processes?
According to Brian Hengesbaugh, AI agents have no privacy rights, so employers can monitor agent logs and telemetry without employee consent or works council consultation; however, standard breach-notification and contractual obligations still apply when personal data is exposed.
How should organisations limit what an agent can do?
Practical measures include mapping agent access in an inventory, enforcing least-privilege roles, using just-in-time credentials and applying action whitelists that prevent agents from executing high-risk commands without escalation, a set of controls Baker McKenzie recommends to reduce attack surface.
Related reading
