Your IGA can already govern AI agents
Give each agent an identity, a sponsor, and roles your IGA can assign and review. Straza enforces that access when the agent calls a tool.
On this page6 sections
A coding agent can be running on a developer’s workstation the same afternoon an enterprise license is purchased. Deciding what it should be allowed to do takes more work.
If the agent runs with the developer’s credentials, it may inherit access well beyond its task. The extent depends on the credentials available to it, the workstation’s permissions, and any sandbox or tool restrictions.
Three questions matter:
- Whose access is it using? If the agent acts through a human’s account, the target system’s audit log may attribute its actions to that person.
- Where is the action checked? Filtering the model’s conversation does not, by itself, enforce authorization when a tool executes.
- Who maintains the permissions? A local allowlist can restrict an agent, but someone still has to own it, review it, and update it when the agent’s job changes.
Take a developer asking an agent to fix a flaky test and open a pull request. It needs the repository, a shell, and perhaps Jira. If production credentials are also available in that environment, the agent may be able to use those too. The task does not require that access.
This is the agent I’ll enroll as java-developer-agent.
Give the agent a lasting identity
An agent process can be short-lived. The identity accountable for its work does not have to disappear with it.
Without that distinction, basic governance questions become difficult:
- Which identity performed the action, and who owns it?
- What access should a reviewer certify?
- Who removes that access when the job ends?
IGA already gives us a way to manage ownership, role assignments, access reviews, and revocation. I wanted to use those mechanisms for agents too.
A name tag is not an identity
Take the reframe seriously and two prerequisites follow:
- Every agent needs a stable, verifiable identity.
- An agent must not be able to modify its own identity or its guardrails.
For MCP access, Straza needs an authenticated identity it can use to resolve the agent’s permissions. A caller-supplied identity header is not sufficient on its own: the receiving system must verify who supplied it and whether they are authorized to act as that identity.
Your IGA provisions agent identities into Straza over SCIM 2.0 and manages their role assignments and sponsors. The sponsor is the human accountable for the agent.
Straza can also act as the identity provider for those agents. A headless agent authenticates with a signed assertion using its own key; Straza verifies it against the registered public key and issues a short-lived token. No browser login or password is needed. This also works in enterprise deployments where humans sign in through an external identity provider, so each agent does not need a separate registration there. Agents can use the external provider instead if that is how you want to manage their credentials.
With this, agents get permanent identities tied to positions: java-developer-agent, accounting-agent. The same model as people.
For calls through Straza, the session identifies the agent and resolves its assigned roles. Those assignments determine which MCP tools it can access. For calls requiring approval, the record also names the sponsor accountable for the agent and the person who decided.
That identity does not remove credentials the agent may already have elsewhere. The deployment must also restrict direct access to systems that are meant to be reached through Straza.
The control plane is just another target system
Your IGA cannot talk to a terminal agent directly. In between sits a control plane: it distributes guardrails and policy snapshots to agents and controls their access to tools. That control plane is what I built Straza to be.
From the IGA's perspective, that control plane is just another target system: accounts and group memberships over SCIM 2.0, with a plain REST API and an OpenAPI description for the rest. Whether you run midPoint, SailPoint, or anything else, you manage AI agents the way you manage every other identity. No parallel governance stack, no second source of truth.
What an agent sees, and what a human approves
Identity alone is not enough. If your MCP servers touch production, a role model on paper won't save you. Two controls belong at the tool level.
Visibility: an agent sees only the tools its role binds
Straza’s MCP catalog exposes only the tools bound to the agent’s roles. If the accounting agent has no role granting deploy_production, Straza leaves that tool out of its catalog and refuses calls to it. This also reduces the tool definitions sent to the model.
Human approval before a tool runs
A policy can require human approval for a tool call. In this example, Straza holds the agent’s call to deploy_production and asks the sponsor to approve or deny it on their phone.
Decisions run against a signed policy snapshot. An approval nobody answers is refused. If Straza is unreachable, calls requiring approval are refused; local decisions can continue only within the signed snapshot’s configured grace window, which is zero by default in the enterprise profile.
Straza injects credentials for its MCP upstreams at the gateway, keeping those credentials out of the agent’s context.
Approvals fit real workflows in two dimensions:
- Who decides: the sponsor, an approver role, or nobody. A rule that names no approver falls to the sponsor; no usable decider is an immediate deny, with the reason.
- How it blocks: a hold, where the call waits a couple of minutes (tunable) for a human, deny on timeout; or a ticket, which never blocks: an immediate deny carrying a ticket reference, and the agent moves on.
Either way an approval binds that exact call, the tool and its arguments, and it is spent on use: one later run passes, within a window you set, then it is gone. Different arguments, new request.
Straza in practice
Here is the model end to end, on the agent from the opening.
Your IGA provisions java-developer-agent into Straza, with human approvers provisioned alongside it. You register your MCP servers in Straza, and agents reach them through one governed endpoint.
The new agent sees no MCP tools until a role grants access. Application roles defined in Straza bind the tools; your IGA imports those roles and manages their assignments. Policies determine which calls require approval and govern local shell, file, and network actions.
An MCP server admin can define application roles for their own server and select the tools each role includes. Your IGA still controls who receives those roles. Defining a role does not grant its creator access to the tools or authority to approve their use.
In this example, the agent’s roles grant the repository and Jira tools it needs, plus deploy_production. A policy requires human approval before the deployment call can run.
Hooks in supported harnesses (Claude Code, Codex, and Gemini CLI) apply policy to local actions. For agents without a harness integration, straza exec provides a governed shell.
Bypassing those local controls does not grant access to Straza’s protected MCP tools: the gateway still requires authentication and role-based authorization. Access outside the gateway depends on the restrictions applied to the agent’s environment.
When the deployment call arrives, Straza holds it for approval. In this example, the sponsor decides. Straza records the decision in a hash chain you can verify, with events available to stream to your SIEM.
Enforcement uses deterministic policy evaluation. Roles and policies are defined in Straza; your IGA manages the identities and assignments used to resolve access. When an identity disable reaches Straza, its sessions are revoked within seconds. An approval can only be used from a live session of the same identity.
If the identity system you already run can create and kill an account over SCIM 2.0 or REST, it can run this. SSO alone cannot; provisioning is the half that matters here.
Use the identity lifecycle you already have
Your IGA can manage an agent’s identity, sponsor, role assignments, and access reviews. Straza connects those assignments to tool access and approval decisions at runtime.
That gives you an agent account whose access you can review and revoke, and a record of its governed actions. When a call requires approval, that record also identifies the human who decided.
Straza launched October 7, 2026 as open source: AGPL-3.0 core, Apache-2.0 SDKs and spec. The code is on GitHub and the docs are at docs.straza.ai.