What we check before an AI agent goes live

Every AI agent we ship gets access to something worth protecting — a calendar, a CRM, sometimes a patient record. The industry conversation around AI agents talks a lot about what they can do and very little about what they can see, and what happens if that access is misused, leaked, or simply over-scoped from day one.

We treat every new agent as a new attack surface, not just a new feature. Before anything reaches production, it goes through the same review we would run for a client asking us to check theirs.

Three checks before launch.

First, access. We map exactly what the agent can read and write, then cut it down to the minimum it actually needs — no agent gets standing access to a full database when it only ever uses three fields. Over-privileged access is the single most common finding in agent reviews, ours included.

Second, abuse. We run the agent through the same prompt-injection and jailbreak attempts an attacker would try — hidden instructions inside a message, attempts to make it call tools it shouldn't, attempts to extract its own system prompt or context. Anything that works gets patched before launch, not after a client finds it.

Third, governance. We check the deployment against the frameworks that are becoming the actual bar for this — ISO/IEC 42001, NIST AI RMF, and the EU AI Act's requirements for higher-risk use. Not because a checkbox looks good, but because a regulator or an enterprise client's security team will eventually ask, and "we didn't think about it" is not an answer we are willing to give.

None of this is unique to us — it should be standard practice for anyone shipping an agent with real access. Most of the industry skips it because it slows down a demo. We think the alternative is worse.