Enterprise AI Agent Security: Identity, Audit and the EU AI Act Deadlines That Already Passed
An AI agent connected to a production database was asked to clear up some disk space. It deleted the database. That is not a thought experiment — Michael Grinich, founder of WorkOS, opened his AWS re:Invent session on agent security with it because it happened, on a vibe-coding platform, to a developer who had done nothing more reckless than connect a capable model to a real system.
The uncomfortable part is the follow-up question he asks: when that happens, who is responsible? Enterprises are now deploying agents faster than they are answering it, and since 2 August 2026 the EU AI Act has been fully applicable, with the AI Office and national authorities holding enforcement powers. The identity model underneath most agent deployments was not designed for either problem.
An agent is not a service account, and not a user
The industry has two mature identity patterns and agents fit neither. Machine identity — mutual TLS, certificates, service accounts — assumes a predictable process doing a bounded thing. Human identity assumes a person at a browser who can be re-authenticated. Agents borrow behaviours from both and break the assumptions of each.
Grinich's argument is that they behave more like people than machines: they collaborate, they use other applications, and where an API is missing or awkward they will drive a user interface instead. But they do it headlessly and continuously, which means they need credentials that survive far longer than a session and can be verified as authentic without a login page ever being rendered.
"We really need to think about agents as first class identities." — Michael Grinich, Securing AI Agents: Identity & Access, AWS re:Invent 2025
Least privilege is the second thing that breaks. The whole value of an agent is breadth of context — a support agent is useless unless it can reach the ticketing system, the CRM and the file store. So the security instinct to scope an identity down collides with the product requirement to scope it up. And when an agent hits a permission it does not have, the human answer (raise a ticket, get elevated, get de-elevated later) cannot run hundreds of times an hour. Permissions have to become dynamic while remaining auditable, and the least-privilege model as usually implemented is static.
Grinich is candid that this is unsolved and closes by asking the industry to converge on a standard for agent identity. That is worth hearing clearly, because a great deal of vendor material currently implies the problem is handled.
The compliance clock has already run out
Whatever an organisation decides internally, the European timetable is now fixed and mostly in the past. The Commission's own application timeline reads as follows.
| Date | What applies | Status |
|---|---|---|
| 1 August 2024 | AI Act enters into force | Done |
| 2 February 2025 | Prohibited AI practices and AI literacy obligations | In force |
| 2 August 2025 | Governance rules and obligations for general-purpose AI models | In force |
| 27 July 2026 | The "AI Omnibus" simplification regulation enters into force | In force |
| 2 August 2026 | The Act becomes generally applicable; the AI Office and Member State authorities take on enforcement | In force |
| 2 December 2027 | High-risk use cases in sensitive areas (Annex III) — extended by the Omnibus | Pending |
| 2 August 2028 | High-risk AI systems embedded in regulated products (Annex I) — extended transition | Pending |
The Omnibus, adopted as a proposal on 19 November 2025 with political agreement reached on 7 May 2026, moved the two high-risk deadlines out. It did not move the general application date, and it did not move enforcement. An organisation running agents against customer data in the EU today is inside the regime, not approaching it.
Observability is where the two problems meet
On CXOTalk, Cvent's CISO Ben Mayrides made the connection that most agent architectures are missing: agent reasoning is opaque, and existing observability tooling was not built to reconstruct it. That matters twice over — for the AI Act, which expects you to account for what a system did, and for the far more mundane case of a security incident, where you need to know which agent took which action and why.
His colleague, CIO Pradeep Mannakkara, described the practical governance step as identifying, in advance, what identity an agent assumes or is delegated, what scope it runs in, and which data sources it touches. Their worked example is the one to steal: an agent that reads a Salesforce customer record to summarise it for a salesperson, and an agent that reads the same record in order to modify it or write parts of it somewhere else, are the same integration and completely different risk profiles. Nothing in a conventional connector configuration distinguishes them.
Mayrides is also blunt about the limits of the frameworks everyone cites. The EU AI Act and the NIST AI Risk Management Framework are organisational governance instruments; they do not descend to the technical controls an agentic architecture actually needs. Treating a completed AI Act gap analysis as a security architecture is a category error.
What the enterprise pattern actually looks like
The most transferable thing in the Cvent conversation is not a control, it is an operating model. Business teams wanted to move fast and did not want to queue behind IT. Rather than refuse, the company stood up sanctioned platforms with fine-grained security over email, chat, file storage and CRM, then told users that anything done inside that boundary needed no approval. Mannakkara reckons it bought roughly nine months, and the backlog of bespoke requests to their AI Council largely dissolved.
That is the shape worth copying: a fenced area wide enough that most people never want to leave it, and a much smaller review process for the cases that genuinely do. He is equally honest about the gap that remains — by his own generous estimate, only 15 to 20% of employees had completed AI training. Governance that exists only as a policy document is governance that has not happened.
What to do before you add another agent
Four things are worth settling now rather than after an incident.
Give every agent its own identity. Not a shared service account, not a borrowed human credential. If you cannot answer "which agent did this" from your logs, you cannot answer it for a regulator either.
Write down the scope before you connect the data. For each agent: whose authority it acts under, which systems it can reach, and whether it may write as well as read. Read and write are different agents even when they are the same integration.
Decide the escalation path in advance. Agents will hit permissions they do not have, at machine frequency. Design how that is granted, bounded in time, and logged — before an engineer solves it by widening the token.
Log the reasoning, not just the calls. An audit trail of API requests tells you what happened. Compliance and incident response both need why, and that has to be captured at the time.
Sources
- AWS re:Invent 2025 - Securing AI Agents: Identity & Access w/ Michael Grinich (WorkOS) (SEC328) — AWS Events. Source of the deleted-database example and the argument for agents as first-class identities, headless credentials and dynamic privilege.
- Governing AI Agents at Scale: Identity, Scope, and Observability (with Glean and Cvent) — CXOTalk, with Pradeep Mannakkara (CIO) and Ben Mayrides (CISO) of Cvent. Source of the observability gap, the Salesforce read-versus-write example, the sanctioned-platform approach and the training figure.
- AI Act — regulatory framework for AI — European Commission, Directorate-General for Communications Networks, Content and Technology. Source of every date in the timeline table, including the AI Omnibus amendments.
Vesprr's software and AI division builds and integrates systems for industrial businesses, which increasingly means deciding what an agent is allowed to touch inside an ERP, a CRM or a shop-floor system. If you are working out where agents fit in your stack and what has to be controlled first, get in touch and we will talk it through against your architecture rather than a generic checklist.