# How to Run an IGA Access Review on an AI Agent Before You Approve It > Source: > Published: 2026-09-18 00:00:00+00:00 # How to Run an IGA Access Review on an AI Agent Before You Approve It How to generate identity governance (IGA) access-review evidence for an MCP or A2A AI agent, and get it into Okta, SailPoint, or Saviynt certification workflows. 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](https://contextiq.trango-compute.com/agent-readiness-detector) against an MCP server or A2A agent you're about to grant access to, and read the packet before you approve it — not after. Follow Trango Compute on LinkedIn We post updates on new tools, context engineering patterns, and LLM cost research. [Follow on LinkedIn](https://www.linkedin.com/company/trango-compute)