Most enterprise security teams have a mature process for reviewing application architecture, but AI agents introduce components that traditional application security reviews were not built to evaluate. An agent can authenticate independently, call external tools, retain context across sessions, and delegate actions to other agents. Without a review document structured around these specific elements, security teams tend to either apply generic AI risk checklists that miss agent-specific failure modes, or skip formal review entirely and discover gaps after an incident. No single industry standard currently defines this document format. Guidance from the Model Context Protocol specification, OWASP's agentic AI risk categories, NIST's AI Risk Management Framework, and joint CISA/NSA guidance on securely deploying AI systems each address part of the problem. A rigorous review document synthesizes these into a single artifact that maps to how the agent is actually built, not to abstract risk categories.
Document agent identity separately from human identity
The review should open with a dedicated section on how the agent authenticates, distinct from how the humans who configured or triggered it are identified. This includes the credential type the agent uses to call tools and APIs, whether that credential is scoped to the agent itself or inherited from a human session, and how the agent's identity is verified by downstream systems it interacts with. CISA and NSA guidance on securely deploying AI systems recommends applying zero-trust principles, including continuous verification of identity, to AI system components rather than treating initial authentication as sufficient for the life of a session. The review document should record whether continuous verification is implemented or whether the agent operates on a long-lived credential issued once at session start, since the latter increases exposure if that credential is compromised mid-session.
Evaluate tool-call permissions at the function level
A common gap in agent deployments is granting permissions at the agent or session level rather than per tool or function. An agent authorized to "access the CRM" rather than "read customer contact fields" carries materially higher risk if compromised or if it takes an unintended action. OWASP's guidance on agentic AI applications identifies excessive agency and unscoped permissions as risk categories distinct from prompt injection, and recommends human-in-the-loop controls and explicit permission boundaries for autonomous actions. The review document should list each tool or function the agent can invoke, the specific permission scope granted for that call, and whether that scope matches the minimum required for the agent's documented task. Where broader scopes are granted for convenience, the document should record this as a specific finding with a stated justification or a remediation plan, not omit it.
Assess memory, context sharing, and confused-deputy risks
Beyond identity and permissions, the review document should assess how the agent's memory and context-sharing mechanisms handle data across sessions, users, or tenants. An agent that retains context from one user's session into another's, even unintentionally, represents a data leakage risk that standard application reviews rarely test for. The document should also record any confused-deputy risks: scenarios where an agent's delegated credentials, granted for one purpose, could be reused or misused to access resources outside the original intent. The MCP specification explicitly documents this class of risk and states that servers should implement input validation and least-privilege access to the systems they expose as tools, rather than trusting that upstream agent-generated requests are already safe.
Runtime enforcement versus static pre-deployment review
A review document that only validates configuration at a point in time before deployment does not account for how agent behavior can change through updated prompts, new tool integrations, or model updates. The document should distinguish between static controls, such as configuration review and permission audits performed before go-live, and runtime controls, such as pre-execution validation of tool calls or sandboxing of agent actions during operation. NIST guidance on AI system risk documentation emphasizes mapping system components and data flows for traceable assessment, but traceability alone does not prevent an out-of-scope action at execution time. Where runtime enforcement is absent, the review should record this explicitly as a residual risk rather than implying that static review provides ongoing assurance.
Runtime governance as a distinct control layer
Trussed AI's runtime governance capabilities apply policy enforcement and monitoring during agent execution, which is a distinct control layer from the pre-deployment review document itself and should be documented as such when present.
Audit logging and review cadence
The final core section of the document should record what the agent's audit trail actually captures: tool-call inputs and outputs, intermediate reasoning steps where applicable, and the identity context under which each action was taken. NIST guidance on AI system logging recommends retaining sufficient audit trail data to reconstruct AI system decisions and actions for incident investigation, and the review document should state plainly whether current logging meets that bar or falls short of it. The document should also define a recurring review cadence tied to changes in agent capability, new tool integrations, or expanded permission scopes, rather than treating the review as a one-time gate before initial deployment. Finally, the document should name who is accountable for approving residual risk when full remediation of an identified gap is not feasible before deployment, since undocumented risk acceptance is itself a governance gap.