How to Run an AI Agent Control Gap Assessment in 10 Days

Why a Time-Bound Assessment Matters

Most enterprises deploying AI agents cannot answer basic questions about them: how many exist, what systems and data they can reach, and whether anyone is enforcing limits on their behavior at runtime. This is not a failure of intent. It is a byproduct of how quickly agents get built and connected to tools, APIs, and internal data sources, often outside the review processes applied to traditional software. A control gap assessment is a structured way to close that visibility deficit quickly rather than waiting for a governance program to mature on its own timeline. Ten days is a realistic window if the assessment is scoped narrowly around four control domains: identity, permissions, runtime policy enforcement, and auditability. It is not enough time to fix anything. It is enough time to produce an accurate picture of where the organization stands and what needs to happen next.

What You Need Before Day One

The 10-day timeline only holds if certain inputs are available before the assessment starts. At minimum, the team needs a starting list of known AI agents or agentic workflows, even if incomplete, along with contact points for the engineering and application owners responsible for each. Access to identity provider configurations and any tool or API integration records is necessary to evaluate how agents authenticate and what they can reach. Existing policy definitions, guardrail configurations, or approval workflows, if they exist, need to be pulled together so they can be compared against actual behavior. Finally, whatever logging currently exists for agent tool calls or actions needs to be identified and made accessible. If any of these inputs require weeks of internal negotiation to obtain, the 10-day window is not realistic and the assessment should be rescoped before it begins.

The Four Control Domains

Identity concerns how an agent authenticates and whether that identity is distinct, traceable, and revocable, as opposed to a shared service account with no clear ownership. Permissions concern what the agent can actually do once authenticated: which tools it can call, which data it can read or write, and whether that access reflects least privilege or was granted broadly for convenience. Runtime policy enforcement concerns whether there is an active mechanism checking agent actions against defined rules before or as they happen, rather than a written policy that nothing actually enforces. Auditability concerns whether agent actions are logged with enough fidelity to answer basic incident questions after the fact, such as what data was accessed, what tool was called, and by which agent identity.

An immature state in any of these domains typically looks like broad, unreviewed access, no consistent enforcement point, and logs that are incomplete or scattered across systems that were not designed with agents in mind. A more mature state has scoped permissions tied to defined agent identities, a policy enforcement layer that agents cannot bypass, and centralized logs sufficient for audit and incident response.

Where Model Context Protocol Fits

Many enterprise agents now connect to tools and data sources through protocols like MCP, which standardizes how an agent discovers and invokes external capabilities. This matters for the assessment because it changes where permission and policy checks need to happen. If an agent can reach an MCP server that exposes a broad set of tools, the assessment needs to determine whether access to those tools is scoped per agent or granted wholesale, and whether there is any enforcement point between the agent and the tool call itself. Assessors should treat MCP connections as a distinct category in the permission map rather than folding them into general system access, since the failure modes (an agent invoking a tool it was never intended to use) are specific to how these integrations are configured.

From Findings to Remediation

The assessment output should be a short list of concrete gaps tied to specific agents and control domains, ranked using the criteria above, not a general maturity narrative. Remediation planning is a separate exercise from the assessment itself, but the roadmap produced on days 9 and 10 should give governance and security leaders enough to sequence work: which gaps require immediate access restriction, which require building out enforcement mechanisms that do not yet exist, and which are lower priority because exposure is limited. This is also where organizations typically decide whether existing IAM and logging infrastructure can be extended to cover agents, or whether a dedicated runtime governance layer is needed to enforce identity, permissions, and policy consistently across every agent and tool integration, including those connected through MCP.