Okta issues the identity. Guard governs the action.
Okta AI Agent Import pulls every agent identity from Gemini Enterprise, DataRobot, Workday, Microsoft, Glean, and LangSmith into one directory. Guard sits at the wire and decides whether each of those identities is allowed to take the action it just requested. Same pattern as Okta plus a PAM tool for humans.
Your identity provider tells you who your agents are. Guard governs what they do.
Why identity alone is not enough.
Every builder platform ships its own agent registry.
Gemini Enterprise, DataRobot, Workday, Microsoft, Glean, LangSmith, Claude Managed Agents. Each maintains its own list of agents, its own owners, its own lifecycle. Your security team has to hunt across every platform to answer one question.
Identity is not enforcement.
Okta answers who owns the agent and how to deactivate it. Neither Okta nor the source platform answers whether the agent should be allowed to issue that refund right now. Runtime governance is a separate layer.
Agents outpace governance without both layers.
Gartner projects 40 percent of enterprise apps will run task-specific agents by end of 2026. Fewer than a third hold agents to human-identity standards. Filling that gap needs identity discovery and runtime enforcement, not one or the other.
Three questions, two layers.
Okta's own security framing names three questions. Okta owns the first and helps with the second. The third is where Guard operates.
Where are they?
Okta AI Agent ImportOkta pulls agent identities from every supported builder platform into one directory. Owner, lifecycle, deactivation, access certifications. This is the discovery layer.
What can they connect to?
Okta plus GuardOkta handles the access model at the entitlement layer. Guard adds runtime scope: which credentials the agent may broker at run time, which resources fall inside the current session's permit.
What can they do?
Conduct GuardGuard evaluates every model call, MCP tool call, and action-tool call against policy. Allow, warn, or block returns before the action commits. Every decision lands in the hash-chained audit.
Two layers, one governance story.
Okta issues. Conduct governs. The same layer split that Okta plus a privilege-access tool uses for humans, applied to the agent identity class.
The identity layer.
Okta AI Agent Import
Discovers agents across Gemini Enterprise, DataRobot, Workday, Microsoft, Glean, LangSmith, and Claude Managed Agents. Assigns owners. Runs access certifications. Handles deactivation and lifecycle. One identity registry across every builder platform.
The runtime layer.
Conduct Guard
Consumes the identity registry as a source of Guard principals. Every Okta-imported agent becomes a first-class principal in Guard policy. Runtime decisions cite the Okta identity in the audit chain. Agents can authenticate to Guard with their Okta-issued JWTs, so Okta remains the single credential system.
Reference architecture.
How Okta AI Agent Import feeds Conduct Guard.
- 1. Okta imports agents from builder platforms. AI Agent Import pulls agent identities from Gemini, DataRobot, Workday, Microsoft, Glean, LangSmith, and Claude Managed Agents. Each agent gets a base profile with owner, source platform, and lifecycle state.
- 2. Guard pulls the identity registry from Okta. An on-demand sync mirrors the Okta agent identity registry into Guard's agent-identity module. Owner is assigned on the first sync. Source platform and lifecycle state carry over on every sync. Scheduled sync is on the roadmap.
- 3. Guard principals reference Okta identity. Every Guard policy rule can reference the Okta-imported identity as a principal. The audit chain records the Okta identity on every decision, giving auditors an accountable human on every row.
- 4. Lifecycle changes propagate. Deactivating an agent in Okta marks it inactive on the next sync. The Okta status field is the source of truth for whether the identity is live. Runtime enforcement of Okta status is on the roadmap.
- 5. One control plane for humans and agents. Access reviews in Okta cover both classes of identity. Runtime enforcement in Guard covers both classes of action. Compliance evidence attaches Okta identity to every Guard decision.
Available now. Configure at Agent Identity → Integrations.
Runtime authentication
Agents authenticate to Guard with their Okta identity.
No shared secrets between Okta and Conduct. Agents present an Okta-issued JWT. Guard verifies it against your Okta authorization server and treats the identity as a first-class Guard principal for policy evaluation.
Setup
- 1. Create an OAuth authorization server in Okta admin.
- 2. Paste the issuer URL and audience into Agent Identity → Integrations.
- 3. Toggle Enabled.
Runtime flow
- 1. Agent requests a token from Okta.
- 2. Agent calls Guard proxy with the Okta JWT as a Bearer token.
- 3. Guard verifies the JWT against Okta JWKS, evaluates policy, and forwards to the LLM.
One control plane for identity and action.
Okta issues the identity. Guard governs the action. Book a reference walkthrough or read the deep dive.