{"slug": "how-to-run-an-iga-access-review-on-an-ai-agent-before-you-approve-it", "title": "How to Run an IGA Access Review on an AI Agent Before You Approve It", "summary": "Agent Protocol Inspector generates a structured IGA Review Packet from MCP and A2A agent scans, producing a recommended decision, risk breakdown, reviewer and owner questions, and export formats for Okta, SailPoint, and Saviynt certification workflows. The tool maps the highest declared risk to a decision — critical to block, high to approve_with_changes, medium to review, and low or none to approve — and derives every sentence from fixed templates keyed to rule matches rather than an LLM call, which the tool's documentation says avoids a prompt-injection surface in text controlled by untrusted third parties. In one example, scanning a live A2A agent card declaring a check-well-known-discovery skill returned recommendedDecision \"approve_with_changes\" because fetching arbitrary remote URLs was classified as a high-risk browse_web capability.", "body_md": "# How to Run an IGA Access Review on an AI Agent Before You Approve It\n\nHow 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.\n\nMost 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.\n\n**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.\n\n## What Goes Into the Packet\n\nThe 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:\n\n- **`recommendedDecision`** —` approve` ,`approve_with_changes` ,`review` , or`block`\n- **`decisionReason`** — which specific capability drove that decision\n- **`highestRisk`** — the ceiling risk level across every declared capability\n- **`systemsTouched`** /**` dataTouched`** — the endpoints and data categories the agent can reach\n- **`risks[]`** — every high/critical finding, each with its own explanation, remediation, and evidence\n- **`reviewerQuestions[]`** and**` ownerQuestions[]`** — specific, capability-driven questions a human reviewer should actually ask\n- **`recommendedRemediations[]`** — concrete next steps before approval\n\nThe decision rollup is a simple, disclosed ceiling function, not a hidden score:\n\n| Highest declared risk | Recommended decision | \n|---|---|\n| critical | block | \n| high | approve_with_changes | \n| medium | review | \n| low / none | approve | \n\n## Why It's Deterministic, Not LLM-Generated\n\nEvery 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.\n\n## A Real Example\n\nScanning 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:\n\n\"What SSRF protections, redirect limits, response-size caps, and private-IP/metadata-endpoint blocking does this agent's own URL-fetching capability implement?\"\n\nThat'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.\n\nThe 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.\n\n## Getting It Into Your IGA Platform\n\nNone 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:\n\n**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:\n\n```\nreviewSystem,agentName,target,applicationName,system,owner,accountOrPrincipal,entitlementOrTool,normalizedCapability,risk,evidence,recommendation,recommendedDecision\n```\n\n**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:\n\n```\nusername,applicationName,ent_generate_agent_metadata,ent_search_or_retrieve_data,ent_execute_code_or_shell_commands\n```\n\n**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.\n\n## Try It\n\nEvery 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.\n\nRun [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.\n\nFollow Trango Compute on LinkedIn\n\nWe post updates on new tools, context engineering patterns, and LLM cost research.\n\n[Follow on LinkedIn](https://www.linkedin.com/company/trango-compute)", "url": "https://wpnews.pro/news/how-to-run-an-iga-access-review-on-an-ai-agent-before-you-approve-it", "canonical_source": "https://contextiq.trango-compute.com/blog/ai-agent-access-review-iga-okta-sailpoint-saviynt", "published_at": "2026-09-18 00:00:00+00:00", "updated_at": "2026-09-28 15:19:57.216786+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-safety", "ai-tools"], "entities": ["Agent Protocol Inspector", "Okta", "SailPoint", "Saviynt", "MCP", "A2A"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-to-run-an-iga-access-review-on-an-ai-agent-before-you-approve-it", "markdown": "https://wpnews.pro/news/how-to-run-an-iga-access-review-on-an-ai-agent-before-you-approve-it.md", "text": "https://wpnews.pro/news/how-to-run-an-iga-access-review-on-an-ai-agent-before-you-approve-it.txt", "jsonld": "https://wpnews.pro/news/how-to-run-an-iga-access-review-on-an-ai-agent-before-you-approve-it.jsonld"}}