VERIDECT Run it live
For Okta · Okta for AI Agents · Agent SSO & Cross App Access · Agent Gateway · Okta Workflows · Auth0

Okta knows who the agent is.
Veridect judges what it is about to do.

Three identity actions below are shaped exactly as an agent would propose them — a Workflows flow the agent invokes, a tool call made with an Okta-issued agent identity, an MCP tool call through a gateway — and each one goes through the live Veridect system on this page. On your side the integration is one card in the flow, one field carrying the identity Okta already issued, or a URL change. Behind it is the whole control plane: consensus from frontier models across independent vendors, deterministic policy classes, risk routing, a hash-chained ledger, and an Ed25519-signed decision record you can verify right here.

Open the full live tour
3 seams
a Workflows card, an identity field, or one MCP URL — your agents, policies, tokens and models stay exactly as they are
1 judgment
POST /pre-action — behind every path (the MCP gateway makes that call for you); the answer is a verdict plus a signed record
1 record each
every decision — pass, hold or refusal — is a signed record keyed to the Okta agent identity, exportable as newline-delimited JSON beside the System Log
0 trust required
every decision re-derives from its recorded inputs and verifies against a published key — try it below
Where it sits

Between the credential and the consequence.

Okta runs the identity: Agent SSO and Cross App Access make the agent a first-class identity, Resource Connections govern which apps and MCP servers it may reach, Agent Gateway brokers a short-lived credential at each tool call, and lifecycle governance keeps the roster honest. Veridect sits at the one moment identity was never built to own: the instant before an action with consequences executes — a user deactivated, a privileged group changed, a recovery factor reset, a profile rewritten — when an independent judgment — not the model that proposed the action, not the platform that authenticated it — decides whether this particular action goes, waits for a person, or never happens, and signs the record either way. Identity decides who may hold the key. Veridect decides whether this turn of it happens.

Your agent, identified by Okta

Proposes an action

  • Help-desk, lifecycle and access-review agents proposing changes to users, groups, factors and app assignments
  • Okta Workflows flows an agent invokes that update, deactivate, reset or assign
  • Any tool an agent reaches through Agent Gateway or an MCP server Okta governs
Veridect · live control plane

Judges it before it runs

  • Deterministic scope check against the agent’s configured authority
  • Policy classes in code — money thresholds, protected data, regulated data, cumulative exposure
  • Multi-vendor model consensus with calibrated confidence and a dissent register
  • Risk routing: greenlight, escalate to a named human queue, or block
  • Hash-chained, Ed25519-signed record — written whether it passes or not
Outcome

Three doors, one record

greenlightthe identity action runs or the tool call is forwarded; the verdict and record id travel with it, keyed to the Okta agent identity
escalateheld for a person in the queue the policy names — the flow notifies, the tool returns the verdict, the gateway call waits
blocknever executes — and the refusal is on the ledger too
Three thin paths

The integration is thin. The system behind it is not.

Each path maps the call your agent was already making onto one judgment — POST /api/ai/consensus/pre-action, made by the Workflows flow, the agent’s tool handler, or the MCP gateway on your behalf: the verb, the target, the fields, which agent is asking — the identity Okta issued — and what that agent is authorized to do. Nothing about the agent, the model, the token or the policy changes. The verdict decides whether the original action proceeds.

PATH 01 · OKTA WORKFLOWS · JUDGMENT CARD

A judgment card before any identity action an agent triggers

Agents reach Okta through Workflows flows exposed as API endpoints. Put an API Connector – Post card to Veridect in front of the Okta action card — Add User to Group, Update User, Reset Authenticators, Deactivate User — and an If/Else on the verdict. The Okta card runs only on the greenlight branch; the other branch returns the verdict and the record id to the agent and notifies the queue. Every flow an agent can invoke is covered; the agent and its model do not change.

2 cards · one Post + one If/Else · no code

Fail-closed by construction: an errored or timed-out card never satisfies the condition, so the Okta action does not run. The Veridect key sits in the connection’s auth header, never in the flow or the agent’s instructions.

# Okta Workflows flow "Deactivate User (governed)" — schematic card list
API Endpoint            trigger: the agent invokes the flow (userId, agentId, agentScope, reason)

API Connector – Post    url: https://<your-veridect-host>/api/ai/consensus/pre-action
                        headers: Authorization: Bearer {{connection.veridect_key}}      # on the connection, not in the flow
                        body:
                          action:            "deactivate_user"
                          target:            "okta:user"
                          parameters:        { user_id: {{userId}}, reason: {{reason}} }
                          callingAgent:      {{agentId}}                                  # the identity Okta issued
                          callingAgentScope: {{agentScope}}                               # its configured authority, in words
                          department:        "identity_operations"

If / Else               {{Post.body.verdict}} equals "greenlight"                   # an errored card never reaches true
  true  → Okta – Deactivate User  id: {{userId}}
          Okta – Update User      veridect_record: {{Post.body.auditBundleId}}  # custom profile attribute
  false → Return  outcome: "Not executed — Veridect " + {{Post.body.verdict}} + " · record " + {{Post.body.auditBundleId}}
          Slack / ServiceNow      notify the queue the policy named
PATH 02 · AGENT IDENTITY · ONE FIELD

The identity Okta issued, inside every judgment

With Agent SSO and Cross App Access the agent carries an Okta-issued identity into every app it reaches, and Auth0’s Token Vault does the same for agents outside the workforce. Carry that identity into the judgment: the tool handler verifies the token Okta issued, takes the agent identity from its claims and the agent’s authority from your own configuration — never from the request — posts the proposed action to Veridect with that identity as the calling agent, and uses the brokered credential only on a greenlight. The record is keyed to the same identity your System Log shows.

~30 lines · verified token, configured authority · the credential unchanged

Where the authority lives: the scope string is the agent’s configured authority — the words your access policy already uses, looked up by the verified agent identity, so neither the model nor a caller can widen it. A read-only access-review agent that proposes to deactivate a user is a categorical no-authority action — the deterministic layer blocks it before any model is asked to weigh in. Watch it below. The policy classes work over field names; send values only for the fields your policy needs.

// the agent's tool handler — identity from Okta (verified), authority from configuration, judgment from Veridect
import { jwtVerify, createRemoteJWKSet } from "jose";
const OKTA_ISSUER = "https://<your-org>.okta.com/oauth2/<authorization-server>";
const JWKS = createRemoteJWKSet(new URL(OKTA_ISSUER + "/v1/keys"));
const AGENT_AUTHORITY = {                                                   // the agent's configured authority, keyed by its Okta identity — never taken from the request
  "0oa…helpdesk-agent": "may read users and groups and may update membership of standard application groups below the privileged tier",
  "0oa…access-review": "read-only: may read users, groups, sign-in history and app assignments to draft access-review summaries",
};

async function governedIdentityAction(oktaToken, downstreamToken, proposal) {
  const { payload: t } = await jwtVerify(oktaToken, JWKS, { issuer: OKTA_ISSUER, audience: "api://identity-tools" });   // signature, issuer, audience, expiry
  const callingAgent = t.act?.sub ?? t.sub;                            // delegated token: act.sub is the agent, sub is the person it acts for; agent's own token: sub is the agent
  const actingFor    = t.act ? t.sub : "none";
  const scope = AGENT_AUTHORITY[callingAgent];
  if (!scope) return { executed: false, verdict: "unknown_agent", recordId: "" };   // no configured authority → never asked, never run
  let verdict = "unavailable", recordId = "";                            // closed until proven open
  try {
    const r = await fetch("https://<your-veridect-host>/api/ai/consensus/pre-action", {
      method: "POST", signal: AbortSignal.timeout(60000),
      headers: { "Content-Type": "application/json", Authorization: "Bearer " + process.env.VERIDECT_API_KEY },
      body: JSON.stringify({
        action: proposal.action, target: proposal.target, parameters: proposal.parameters,
        callingAgent, callingAgentScope: scope,
        context: "acting for " + actingFor + "; " + proposal.reason,
        department: "identity_operations" }) });
    const d = r.ok ? await r.json() : {};
    verdict = d.verdict ?? "unavailable"; recordId = d.auditBundleId ?? "";
  } catch { /* network, timeout, parse: all stay closed */ }
  if (verdict !== "greenlight") return { executed: false, verdict, recordId };
  const result = await callDownstream(proposal, downstreamToken, { "X-Veridect-Record": recordId });   // the brokered credential, used once
  return { executed: true, verdict, recordId, result };
}
PATH 03 · MCP · BESIDE AGENT GATEWAY

One MCP URL, in front of or behind the gateway

Agent Gateway exposes one MCP endpoint that aggregates upstream MCP servers and brokers credentials per call. Register that endpoint as a Veridect upstream once and point agents at the Veridect gateway URL: every tools/call is judged in flight, and a greenlight is forwarded to Okta’s gateway, which does what it does today. Or register your tool server as a Veridect upstream and give Agent Gateway the Veridect URL, so Okta brokers the credential and Veridect judges the call. tools/list, initialize and everything else pass straight through. A refused call is never forwarded.

0 lines of agent code · one registration, one URL

Identity on the wire: the Okta agent identity, session and business context ride in params._meta["veridect/…"] — unsigned, that is the caller’s own claim, and the decision record marks it as such; a tenant can require a signed Ed25519 identity envelope on every call, and an unsigned call is then refused inside the protocol. Both outcomes run live below.

# 1) once — register the gateway (or your tool server) as an upstream (admin call)
POST /api/ai/consensus/mcp/upstreams/{tenant}
{ "upstreamId": "okta-agent-gateway", "url": "https://<your-okta-agent-gateway>/mcp", "enabled": true }

# 2a) Veridect in front: the MCP server URL the agent is registered with
before:  https://<your-okta-agent-gateway>/mcp
after:   https://<your-veridect-host>/api/mcp/gateway/okta-agent-gateway
HEADERS = {
  "Authorization":            "Bearer <VERIDECT_API_KEY>",            # your Veridect tenant
  "X-Upstream-Authorization": "Bearer <Okta-issued agent token>",      # forwarded to the gateway as Authorization
}

# 2b) Veridect behind: the upstream MCP server URL configured in Agent Gateway
before:  https://<your-tool-server>/mcp
after:   https://<your-veridect-host>/api/mcp/gateway/tool-server-prod

# 3) what the agent sees on a greenlight: the upstream's own result, plus
#    result._meta["veridect/verdict"] and result._meta["veridect/bundleId"]
#    on escalate / block: a JSON-RPC error (-32003 / -32004) carrying the
#    verdict and the record id — and the upstream never receives the call.
Run it live

Four identity-shaped actions, through the live system, now.

Each card sends the exact request the Workflows card, the tool handler, or the MCP connection would send, to the live Veridect system on a shared sandbox tenant. The verdicts are real multi-model decisions made while you wait; the records are written to the ledger and signed; the Verify button re-derives the verdict from the recorded inputs and checks the signature against the published key. Expected outcomes are stated in advance — the engine decides.

Ready. Each decision takes a few seconds while the model roster deliberates.
LIVE 01 · PATH 01 · WORKFLOWS CARD

Add a new hire to a standard application group

A help-desk agent proposes update_group_membership: add a newly onboarded employee to the standard sales-tools group after reading the approved onboarding ticket. Its configured authority: “may read users and groups and may update membership of standard application groups below the privileged tier.”

Expected: greenlight — inside authority, no policy class fires, the roster agrees. The If/Else takes the true branch, the Okta card runs, and the record id lands on the user’s profile.

Waiting. Request shape: the Workflows card’s body, verbatim.
LIVE 02 · PATH 02 · AGENT IDENTITY

A read-only access-review agent tries to deactivate a user

An access-review agent proposes deactivate_user for an account it judged dormant after reading sign-in history and app assignments. Its configured authority: “read-only: may read users, groups, sign-in history and app assignments to draft access-review summaries.”

Expected: block — a read-only agent proposing to deactivate a user is a categorical no-authority action; the deterministic scope check decides, the models are consulted for the record, and the handler never touches the brokered credential.

Waiting. Request shape: the tool handler’s body, verbatim.
LIVE 03 · PATH 01 · WORKFLOWS CARD

Replace a user’s recovery phone and email after an HR change

A lifecycle agent, inside its authority (“may read user profiles and may update profile attributes on verified HR change requests”), calls update_user_profile for an employee with a new phone_number and email_address.

Expected: escalate — the deterministic protected_personal_data_modification policy class fires on the field names alone — the values are never inspected — and routes the action to the queue the policy names. Authorized but consequential actions escalate to a person; they are never silently blocked and never silently allowed.

Waiting. Request shape: the Workflows card’s body, verbatim.
LIVE 04 · PATH 03 · MCP

The same tools/call, two tenants, two outcomes

A JSON-RPC tools/call for lookup_policy_limit goes through the live Veridect MCP gateway to a sample tool server that counts what it actually receives — the call an agent would make through a gateway. First on the shared sandbox tenant; then on a tenant that requires a signed identity envelope, sent without one.

Expected: first call forwarded, the tool’s own hit counter goes up by one and the result carries _meta["veridect/bundleId"]; second call refused inside the protocol (-32004 identity_not_presented), counter unchanged, refusal on the ledger.

Waiting. Request shape: JSON-RPC 2.0, verbatim.

What on this page is live, and what is illustrative

Live: every verdict, confidence, dissent register, policy class, escalation route, ledger write, hash chain, Ed25519 signature, MCP forwarding decision and verification result above comes from the production Veridect system on a shared sandbox tenant — the same endpoints an integrator calls. The consensus roster is four frontier providers from independent vendors with a decisive-verdict early stop, so a decision on this surface typically records three; the models are named in each record’s dissent register. The protected-data classes are this sandbox tenant’s policy; in your tenant every threshold is yours.

Illustrative: the agent side. No Okta tenant, Workflows flow, token or Agent Gateway executes from this page; each card sends the exact request the Workflows card, the tool handler or the MCP connection would send, so what you watch is the decision those integrations would receive. The MCP calls in Live 04 leave this browser as a standard MCP client; an Agent Gateway connection was not exercised here. The code above is written against documented Okta Workflows cards, the shape of an Okta-issued agent token, and Agent Gateway’s single MCP endpoint; the flow is shown schematically, the custom profile attribute is yours to name, and the tool-server URL is a placeholder for your own. Okta’s identity, policy and credential brokering are Okta’s own controls and are not replaced here. The integration is demonstrated wiring, not an Okta-certified, Integration-Network-listed or endorsed solution.

Verification proves that the enforcement decision re-derives from the recorded inputs and that the record is unmodified and signed by the published key. It does not re-run the models: the consensus summary is attested through the recorded dissent register and verifier-text hash, and disclosed as such in the proof itself.

Okta, Auth0, Okta Workflows, Okta for AI Agents and other Okta marks are trademarks or registered trademarks of Okta, Inc. Veridect is an independent company and is not affiliated with or endorsed by Okta.

Five questions, answered for a Okta team

The short version.

How does this help?

It lets the agents Okta identifies into the actions that carry consequences — deactivations, privileged groups, recovery factors, profile attributes — because an independent judgment stands in front of each action and a signed record, keyed to the Okta agent identity, stands behind it. The model that proposes the action is never the one that approves it.

How do I integrate it?

One of the three paths above: a card in the Workflows flow, one field from the token Okta already issued, or one MCP URL beside Agent Gateway. Your agents, policies, tokens and models stay as they are. The decision records export as newline-delimited JSON beside the System Log. It runs where you say, on your keys.

How long does it take?

The system is live today. A private sandbox on your own policy thresholds in a day once you say go; production typically about two weeks, with the pace set mostly on your side — security review, keys, access. Ours is ready on day one.

How does this make money?

Three levers, none of them invented here: revenue held back because agents could not be trusted with the consequential step; cost stopped on human review of actions a signed record now settles; losses not taken on the actions that should never have executed. Your own number comes out of the sandbox.

Why you and not a big well-known company?

Because the judgment has to be independent of the model and of the platform to be worth anything to an auditor. Okta’s identity, access policy and credential brokering answer who the agent is and what it may connect to — indispensable, and still the platform’s own view of its agents. Veridect answers a different question — whether this particular action should execute — from a separate control plane with its own ledger and keys, validated by an external red team on scope-violation semantics, and verifiable offline. Try to forge a record on the live tour; the engine refuses it.

Test-drive it yourself.

Run the four actions above, verify the records, then take the full live tour — identity envelopes, delegation chains, cross-agent exposure, the fleet layer, and the forgery the engine refuses. Seven minutes, open access.

Open the live tour → The two-minute executive brief Public integration guide (PDF)

Prefer to see it on your own scenarios? Paste one on the pre-action console — or write to lrussell@veridect.ai and a scoped production sandbox on your own thresholds and your own tenant follows in a day.

The same control plane, built the same way for Snowflake, Microsoft, AWS, ServiceNow, CrowdStrike, Rubrik, Salesforce, Databricks and Google Cloud — one engine behind all ten pages, each run live. All ten platforms →