Skip to content
What your client's security team wants from your AI agent
Back to Blog
#AI agents#agent identity#enterprise AI security#EU AI Act#AI governance#observability#least privilege#reshaped-v3

What your client's security team wants from your AI agent

Amir Khan

They want two things, and only one of them is for sale. The first is a named identity for every agent that touches their systems: one account per agent, with a human owner, not a shared service account and not a borrowed user login. That half you can buy. Microsoft Entra Agent ID is generally available, and it is not a Microsoft-only answer, so "our agent runs on Bedrock" or "we built it in n8n" no longer gets anyone out of the question.

The second thing is the one that decides whether the contract gets signed: a record of what the agent decided, and why. Nothing on a shelf sells you that. It has to be captured in your own code, from the first connection, because it cannot be reconstructed afterwards.

Entra's model covers the credential half properly. An agent identity has an owner and a sponsor, a lifecycle, conditional-access controls, and a workflow that transfers sponsorship when the sponsor leaves so no agent is left orphaned with live access. Microsoft also publishes integration patterns for non-Microsoft agents on AWS and GCP, with step-by-step guides for securing an Amazon Bedrock agent and an n8n agent. That matters for what you can be asked: a security team that reads those pages knows the platform has an answer, whatever stack you built on.

Microsoft Learn page headed What's new in Microsoft Entra Agent ID, stating that Entra Agent ID is now generally available
Microsoft's own release note, from What's new in Microsoft Entra Agent ID — Microsoft Learn

What the record has to contain

Prompts, tool calls and the decision trace, stored beside the API log, kept for a period the client names in months rather than one you choose after the fact. An API log will tell an auditor that an agent updated a customer record at 04:12. It will not tell them why the agent picked that record, what it was asked, or which tool returned the value it acted on, and those are the three questions an incident review opens with.

Two design rules make that log worth keeping. Write the scope before the connection, not after: which systems, read or write, under whose authority. An agent that reads a CRM record to summarise it for a salesperson and an agent that reads the same record in order to change it are the same integration and completely different risk, and only the scope document distinguishes them. Second, when an agent meets a permission it does not have, grant it for a bounded period and log the grant. Do not widen the token. Agents hit permission walls at machine frequency, and a token widened once stays wide for the life of the deployment.

Is it the regulator asking, or the client?

The client, for now. The EU AI Act became applicable on 2 August 2026, with the AI Office and national authorities enforcing it. The obligations that bite hardest on deployed systems were pushed back: high-risk uses listed in Annex III apply from 2 December 2027, and high-risk systems embedded in regulated products under Annex I from 2 August 2028, both as a result of the AI Omnibus that entered into force on 27 July 2026.

An ERP or CRM agent at an industrial customer sits outside both annexes for most uses. Treat that as a reading rather than a ruling, and let the client's counsel confirm it against their own use case. The practical consequence holds either way: between now and December 2027 what constrains you is the contract, not the Act, and your client's auditor is reading the same calendar and wants an answer early. That is a reason to write the clause carefully, not a reason to wait.

Connecting an agent to a client's ERP, CRM or shop-floor system and nobody has sent you a clause like this? Send it to them first. Vesprr Software will draft it against your architecture.

Sources