Agentic IGA: How to Govern AI Agent Access and Prove It Worked

Introduction

Your AI agents can already read databases, call APIs and change records. The harder questions come afterwards: who approved that access, does the agent still need it, and did a revoked permission actually stop the action? Agentic IGA (identity governance and administration for AI agents) exists to answer those questions with evidence, not assumptions.

AuthSec connects runtime evidence, access decisions and enforcement results, so every agent's access has an owner, a reason and a test.

Why Logging In Is Not the Problem for AI Agents

Most identity programs were built around a person signing in. Agents change the picture. A single agent can use an operating-system account, a Kubernetes service account and a database login at the same time, and no one of those accounts tells the whole story.

The risk is easy to picture. If an attacker redirects an agent, for example through prompt injection, the agent may use permissions it already holds. The credential is legitimate, but the action is harmful. OWASP describes this pattern as excessive agency (LLM06): too much permission, functionality or autonomy. Governing that access is not a complete defense against prompt injection, but it limits what a redirected agent can reach.

The gap is not login. It is access accountability. That leaves three questions most teams can't answer today, each with a matching control:

• Unknown access. Which workload uses which account to reach your data? Fixed by discovery and the identity graph.
• Unclear accountability. Who approved the access, and does the agent still need it? Fixed by owner reviews.
• Unproven revocation. Did the risky action stop, or did a status in a console just change? Fixed by enforcement tests.

What Agentic IGA Is

Identity governance and administration (IGA) decides who should have access, reviews whether they still need it, and keeps the evidence. Agentic IGA applies that discipline to AI agents and the accounts they use.

The core idea is an identity graph. Instead of separate inventories for workloads, accounts, approvals and logs, AuthSec links the owner, workload, accounts, grant and resource into one explained access path, and keeps the source, time and confidence of each link.

In this example, the Finance team owns invoice-agent. The agent runs as a Linux process under a service account, uses a database login that holds the invoices:read grant, and reaches the invoice database. Because every link is recorded, a reviewer can restrict one path without disabling an account that other agents share.

How It Works: A Five-Step Loop

Access governance is a loop that repeats when access changes. New activity and ownership changes feed the next review.

Verify is the step many programs skip: restrict the access, then test that the action actually stopped.

Evidence an Auditor Can Follow

Every decision should leave a record that links the change to the agent, the approver, the policy and the result. A useful record shows who approved it, when, why, which policy revision applied, what action changed and what happened in the target test. Do not just record a change. Preserve the reason and the result.

These records support an assessment against NIST SP 800-53 controls such as AC-2 (account management), AC-5 (separation of duties) and AU-3 (content of audit records). They support an assessment; they do not equal certification.

What Is Built Today and What Is Still a Target

Agentic IGA is at the design-partner stage, and an open-source release of the IGA core is planned. We would rather be exact about status than oversell it.

Discovery, a review decision and verified enforcement are different milestones. A control that isn't supported on your build is limited to discovery and access-review scope.

• Access certification campaigns with reviewer, rationale, keep/revoke decision and export: built.
• Separation-of-duties evaluator and detective scan: built; wiring into every runtime grant path in progress.
• Grant provenance, owner and orphaned-agent reporting: built for governed agents; binding discovered workloads to owners in progress.
• Local discovery collector, identity graph reader and canvas: foundations built; attribution of workload, account and remote principal in progress.
• Restrict an access path from the graph: design-partner target.
• Verified enforcement with denied-action evidence: pilot acceptance target, supported adapters only.
• NVIDIA OpenShell adapter: integration target.

Agentic IGA vs Agent Frameworks, Sandboxes and Microsoft Entra

These tools solve different layers, and most teams will use more than one.

Microsoft is a real competitor here. Entra and Agent 365 already provide agent governance, though using them for agents requires Agent 365 licensing alongside Entra P1 or Microsoft 365 E3, or Microsoft 365 E7. If that covers your estate, keep it. AuthSec is for the paths it can't yet explain or verify.

Use a framework to build agents. Use AuthSec to govern their access.

• Agent framework (for example Microsoft Agent Framework) controls a tool call through approvals. Agentic IGA reviews the standing access behind the tool.
• Sandbox runtime (for example NVIDIA OpenShell) provides runtime policy and audit for sandboxed workloads. Agentic IGA adds owner reviews and access certification.
• Microsoft Entra Agent ID and Agent 365 provide commercial agent identity, sponsors, access packages and expiry. Agentic IGA tests whether controls cover the exact Linux and Kubernetes accounts, resources and sessions in use.

How to Start: One Workload, One Access Path

You don't need a fleet-wide project to examine agent access. Pick one consequential workload and work through four questions:

For a design-partner evaluation, we agree a restriction on a supported build, apply it, retry the action and record what remains. A permission change is not the same as a failed request, so the test matters more than the console status.

Ready to try it? Request a 20-minute workload review at authsec.ai/contact, read the AuthSec docs or explore the open-source repository at github.com/authsec-ai/authsec.