AI Agent Readiness & Access Audit

An AI agent is not a chat box that produces text. It queries databases, calls APIs, sends email, opens records and deletes them. During a pilot these abilities are usually wired up through one broadly privileged service account, a single API key and a tool list nobody has read line by line. The agent works, the team is convinced, and the same setup quietly moves into production. That is where the trouble starts. A system that cannot show in writing what the agent can reach, which data it sends to which model and whose approval it acts on will either stall at the security and compliance review or, if it gets through, cannot be explained after an incident. The AI Agent Readiness & Access Audit is a fixed-scope engagement built to answer those questions before go-live. What you get at the end is not a list of findings but a readiness file: which agent runs with which permissions, inside which data boundary and behind which approval gates. We covered the background in our article on the real blocker to putting agents into production.

Who this audit is for

It helps in three situations. First, an agent project whose pilot is done and which is waiting on sign-off from security or legal before production. Second, companies where teams have each set up their own agents, automations and MCP connections, and nobody can see from one place any more who connected what. Third, teams that have been asked by a customer, an auditor or an investor for a written account of how they use AI. The audit runs with the same scope whether the agent was built by your team, by a vendor or on an off-the-shelf platform. If there is no agent yet and you are still at the idea stage, this audit is early; starting with a scoping conversation on the AI solutions side makes more sense.

What the audit covers

The scope has six parts and they are the same on every project. Keeping them fixed matters, because the value of an audit comes from nothing being forgotten: a single delete permission in a tool list that nobody remembers can make every other safeguard pointless.

Agent inventory

We start by establishing what actually exists: which agents are running, which model each uses, which tools and systems it is connected to, which identity it runs under, who built it and who owns it. The inventory does not rely on what teams report. It is checked against service accounts, API keys, MCP server configurations and the connections inside automation platforms. In most organisations the first surprise shows up here: the number of agents people declare and the number of live connections rarely match.

Permission and data boundary map

For each agent we put what it does next to what it is allowed to do. An agent that only needs to read but can write, an agent that needs one table but can see the whole database, an agent that should act on behalf of a user but connects with an admin account: the map makes these visible. The output is a recommended least-privilege permission set per agent and a data boundary definition that states which data may leave your systems, that is, go to the model provider. We explained why this permission layer matters more than the protocol itself in our MCP article.

KVKK and GDPR risk assessment

We list, one by one, the kinds of personal data the agent processes, the purpose, whether it is transferred to a model provider abroad, whether the provider uses it for training and how long logs are kept. Special category data, health data for example, is flagged separately. This is a technical assessment. We do not write privacy notices or legal opinions, but we put in front of your legal team the complete, written data flow they need in order to decide.

Audit trail and human approval gates

After an incident the first question is always "what did the agent do, why, and who approved it". We check whether the system records which tool the agent called with which parameters, on whose behalf it acted and what the result was. Then we separate out the irreversible actions, such as payments, deletions, emails sent outside the company or changes to customer records, and define which human approval gate belongs in front of each. Putting approval on every action makes the agent useless; putting it on none makes the risk invisible. The balance is set action by action.

Prompt injection and tool abuse

Every piece of content an agent reads, an email, a web page, a PDF or a customer message, can try to give it instructions. In this attack, known as indirect prompt injection, the agent mistakes a command hidden in the text for its own task and carries it out with the tools it has. We identify every point where the agent meets untrusted content, look at which tools that content could trigger and test it with controlled scenarios. Under the same heading we check whether tool definitions are too broad, whether the agent has any path to widen its own permissions, and whether there are limits on cost and call volume.

Production roadmap

The final output is a written plan that ranks the findings by cost and impact. Which change is mandatory before production, which can be done in the first month, and which can be recorded as an accepted risk; each item comes with an owner role and an acceptance criterion. The plan is written in enough detail for your own team to carry out. It does not have to be implemented by us.

How it runs

The audit takes two to four weeks, depending on the number of agents and how many systems they touch. The first week covers the scoping meeting, access setup and the inventory. We do not ask for write access to your production systems: read access to configuration, the code repository, logs and, ideally, a test environment is enough. Injection and tool abuse tests run only in a test environment or within a limited scope you approve in writing. A short status note goes out at the end of each week, so a critical finding reaches your team without waiting for the audit to finish. In the last week the findings are walked through in separate sessions with the engineering team and with decision makers.

What you receive

• Agent inventory: each agent's model, tools, identity, connected systems and owner.
• Permission and data boundary map: current permissions compared with the recommended least privilege, plus a definition of which data may leave your systems.
• Personal data flow document: data processed, purpose, transfers and retention, ready for your legal team's review.
• Approval gate design: the list of irreversible actions and, for each, the proposed human approval and logging structure.
• Injection and tool abuse findings: scenarios tested, results and recommended fixes.
• Production roadmap: a prioritised work list with owners and acceptance criteria.

What this audit does not do

It does not replace a penetration test: network and application security of your infrastructure are out of scope, the focus is the agent and its connections. It does not give legal advice or certify KVKK or GDPR compliance; it maps the technical data flow. It does not measure the quality or accuracy of the model's answers, which is a separate evaluation. And it does not hand out a "secure" certificate: it gives a written assessment and a to-do list. If the agent's code was written with AI-assisted tools and the application layer also needs a review, we handle that separately under Vibe-Code to Production.

After the audit

You can carry out the roadmap with your own team; the document is written for that. If you would rather hand the implementation to us, narrowing permissions, approval gates, logging and injection safeguards are planned as a separate piece of work. As the number of agents grows, so does the question of who makes these decisions and on what principles; with teams that need ongoing technical leadership we continue this work through CTO as a Service.