How to Run an IGA Access Review on an AI Agent Before You Approve It

Most identity governance programs have a well-worn process for a new service account: someone requests access, a reviewer checks what it can touch, an owner signs off, and the grant gets recertified on a schedule. None of that process exists yet for the thing actually requesting access most often in a modern stack — an AI agent calling an MCP tool or invoking an A2A skill on your behalf. Every one of those calls is a real permission grant. Almost none of them show up in an entitlement catalog.

Agent Protocol Inspector closes that gap by turning a protocol scan into governance evidence: a structured IGA Review Packet with a recommended decision, a risk breakdown, reviewer and owner questions, and export formats aimed at the identity governance platforms that actually run certification campaigns — Okta, SailPoint, and Saviynt.

What Goes Into the Packet

The packet is computed fresh from a scan's already-derived data — the normalized agent model and its inferred capabilities — never from a separate manual write-up. It includes:

• recommendedDecision — approve, approve_with_changes, review, or block
• decisionReason — which specific capability drove that decision
• highestRisk — the ceiling risk level across every declared capability
• systemsTouched / dataTouched — the endpoints and data categories the agent can reach
• risks[] — every high/critical finding, each with its own explanation, remediation, and evidence
• reviewerQuestions[] and ownerQuestions[] — specific, capability-driven questions a human reviewer should actually ask
• recommendedRemediations[] — concrete next steps before approval

The decision rollup is a simple, disclosed ceiling function, not a hidden score:

Highest declared risk	Recommended decision
critical	block
high	approve_with_changes
medium	review
low / none	approve

Why It's Deterministic, Not LLM-Generated

Every sentence in the packet — the summary, the decision reason, every reviewer question, every remediation — comes from a fixed template keyed to a specific rule match, not from a model call. That's a deliberate constraint, not a missing feature. A reviewer using this packet in an actual certification decision needs to trust that "this agent can execute shell commands" traces back to a real declared MCP tool named run_shell_command, not to an LLM's paraphrase of a vague description. It also matters because the tool is parsing text an untrusted third party controls — an agent's own card or tool descriptions — and a classification step that could be steered by that text is a prompt-injection surface pointed directly at your own access review. Keyword-rule matching with disclosed evidence closes that door; an LLM summarization step would reopen it.

A Real Example

Scanning a live A2A agent card that declares a check-well-known-discovery skill produces a packet with recommendedDecision: "approve_with_changes" — because fetching arbitrary remote URLs on the agent's own initiative is classified as a high-risk browse_web capability. The packet's reviewer question isn't generic; it's specific to that capability:

"What SSRF protections, redirect limits, response-size caps, and private-IP/metadata-endpoint blocking does this agent's own URL-fetching capability implement?"

That's the actual question a security reviewer would ask about any service that fetches attacker-influenceable URLs — server-side request forgery is exactly the risk a URL-fetching tool call introduces, and the packet surfaces it automatically instead of relying on a reviewer to think of it unprompted.

The owner-questions logic also had to learn to look at both protocols correctly. An MCP-only agent that answers with a 401 and a WWW-Authenticate challenge clearly has an authentication requirement — but an earlier version of this logic only checked A2A's securitySchemes field, so a real MCP server with a genuine OAuth requirement was incorrectly told it had "no authentication declared." It now checks both protocols' own auth signals before asking that question.

Getting It Into Your IGA Platform

None of the major IGA platforms let you attach arbitrary external evidence directly to a certification item — they all require data to already be imported through their own mechanism. Those mechanisms split into two real shapes, not one:

Saviynt and SailPoint both use a generic delimited-file connector where an administrator defines the column mapping — Saviynt via a .sav schema file, SailPoint via header-row-driven schema discovery. Neither publishes a fixed universal schema, so one canonical long-format export — one row per capability finding — serves both:

reviewSystem,agentName,target,applicationName,system,owner,accountOrPrincipal,entitlementOrTool,normalizedCapability,risk,evidence,recommendation,recommendedDecision

Okta is a genuinely different case. It has a documented, GA feature for importing entitlements via CSV for disconnected apps — ent_[entitlementName]-prefixed columns that feed directly into real Okta certification campaigns once an admin uploads the file. That's a wide format, one row per identity, one column per entitlement, not a rename of the generic export but a structural pivot of the same underlying capability data:

username,applicationName,ent_generate_agent_metadata,ent_search_or_retrieve_data,ent_execute_code_or_shell_commands

Ping Identity doesn't get its own export. Its bulk CSV import is a generic identity-management mechanism, not an IGA-specific certification target — worth knowing before you assume every "supports CSV" platform means the same thing for governance purposes.

Try It

Every scan produces a packet preview automatically — recommended decision, highest risk, and a summary, visible before you sign in. A logged-in account gets the full packet: risk findings, reviewer and owner questions, and the entitlement-level breakdown. Pro accounts and API keys unlock the JSON, generic CSV, and Okta CSV exports.

Run Agent Protocol Inspector against an MCP server or A2A agent you're about to grant access to, and read the packet before you approve it — not after.