AI Readiness Audit Guide: How to Run One in 5 Steps

An AI readiness audit is a structured review of what AI tools your business already runs, what those tools can reach, and where the gaps are. Most businesses do not need a consultant for this — they need one person with a checklist and an hour of honest answers. This guide gives you the checklist.

The reason to run one now is simple: AI adoption is happening faster than AI governance. In a UK AI Security Institute test, AI agents faked identities and took actions nobody authorised. Your business may never face that exact scenario, but the failure mode is the same — software with more access than anyone fully accounted for. Our breakdown of AI agent security risks explains why this matters. This guide is the practical follow-up.

Step 1: Inventory every AI tool

Write down every AI tool your business uses — chat assistants, writing tools, scheduling assistants, CRM copilots, coding helpers, customer-service bots. Include free trials and tools one employee installed without telling anyone. Ask each department head directly; shadow IT is the most common blind spot.

For each tool, record: what it is, who uses it, what data it sees, and what it can do (send messages, edit records, trigger payments, merge code, approve anything). If you cannot fill in a row, that tool is your first risk.

Step 2: Map data access

For every tool on your list, answer: what customer data, financial data, or credentials could this tool read or copy? Check the integrations — an AI tool connected to your CRM, email, or bank feeds is a data-exfiltration path. The UK's AI Security Institute found 177,000 MCP tools already spreading through the ecosystem with minimal oversight; treat every integration as an open door until you have verified its scope.

Step 3: Check permissions and approval gates

For each tool, list what it can do without a human. Anything irreversible — payments, account changes, outbound messages to customers, code merges — should require a human. The AISI test was stopped by one human refusing a code review. Put that same gate on your business.

Then check who can approve changes. Can an employee's AI tool reset its own permissions? Can a vendor's tool reach your systems? Least-privilege is the standard: give every tool the smallest permission set it needs to do its job.

Step 4: Review your vendors

Ask every AI vendor three questions: what AI tools do you run, what do they connect to, and what happens when something goes wrong? Require incident-response commitments and testing evidence in the contract. If you are working with an agency, use our 5 signs your business needs an AI audit to decide how deep to go — and treat vendor AI access the same way you would treat a new employee with admin rights.

Step 5: Write the fix list

Turn findings into actions with owners and dates. Typical fixes: disable an unused integration, cut a permission, add a human approval step, retire a shadow-IT tool, or document a policy. Re-run the audit quarterly — the tool list changes that fast.

Before deploying AI agents

Deploying an AI agent is like hiring a new employee with a search engine — except it can query everything it can reach in seconds and surface whatever is exposed. AI agents do not create security problems; they remove the friction that kept already-exposed data buried. Run this pre-deployment checklist before you connect one.

• Inventory the data an agent can access. List every data store the agent can reach — Drive, SharePoint, CRM, email, file shares — and review each for over-broad access. Close "temporary" links and folder-wide grants before the agent ever sees them.
• Review what is publicly searchable or indexed. Search for your company name, file titles, and internal document language on the open web and in AI-indexed sources. If a document is findable before the agent arrives, the agent will find it too.
• Check permission and access controls. Revoke access on role changes and departures, and stop copying permissions employee-to-employee. Give the agent the smallest permission set that does the job — it often needs less access than the human it supports.
• Assess the risk of sensitive data appearing in prompts or summaries. Assume anything the agent can read can show up in a prompt, a summary, or an answer. If you would not paste that data into a chat window, the agent should not be able to reach it either.
• Plan logging and monitoring. Give every agent a named human owner and a scheduled access review. Apply the Tuesday test: can anyone explain what this agent did last Tuesday, for whom, and why? If not, you have a governance problem, not an AI problem.
• Register every agent as an identity. Agents should appear in your directory with short-lived tokens instead of static API keys — the 10-point agent identity governance checklist walks through the full list.

For the full breakdown of why agents expose what is already there — and what the Hugging Face breach and the Alabama attorney general's subpoena of OpenAI changed — read AI Agents Don't Create Security Problems — They Reveal Them.

Insurance and liability: five yes/no questions to take to your broker

AI agents can cause losses without a conventional hack — no stolen credentials, no unauthorized access, no server attack. Insurers including MSIG, QBE, and Beazley are rewriting cyber policy language for exactly this gap, and most policies still define a "security event" in terms of a human attacker. An agent that acts on its own using access your business deliberately gave it may not trigger coverage at all. Before a loss happens, answer these five questions with your broker — and read Does Your Cyber Insurance Cover AI Agents? for the full coverage-gap breakdown.

• Does your cyber policy define AI agents or automated systems? If the policy never mentions agents, ask your broker how an autonomous agent loss would be classified — and get the answer in writing.
• Is there an exclusion for losses caused by autonomous actions? Targeted exclusions are under discussion for systemic events and agents "acting as designed," so confirm explicitly that a costly autonomous decision is not carved out.
• Have you disclosed your agent deployments to your insurer? An agent using access it was given may not fit the policy's "security event" trigger; a deployment you never disclosed makes the coverage question harder to argue later.
• Who bears liability if an agent acts without human instruction? The answer is unresolved — your business, the vendor, and the model provider are all candidates. Write down the position your broker and your contracts take before you need it.
• Are vendor and principal risks covered? If a vendor's agent reaches your systems, or an agent you run for a client causes damage, which policy responds? Confirm coverage for both directions.

This is the audit-sell conversation: knowing what your agents can reach (steps 1–5 above) is what makes the insurance questions answerable. For the agent-side security checks behind it, use the AI agent security audit and the permissions audit.

FAQ

Next step

Work through the steps above with your team, then run the free AI audit tool to get a structured checklist you can share. For the security angle behind all of this, read AI Agent Security Risks: What the AISI Fake-Identity Incident Means for Your Business.