Enterprise · Security / Identity governance · Live multi-tenant platform · P0 complete across 11 modules
AI agents are identities. Govern them like it.
WonderAgent continuously compares what an agent SHOULD do, what it CAN do and what it DID — and raises an evidence-backed finding the moment they stop agreeing. Read-only to start. Your IAM stays the system of record.
- Platform
- Web · responsive · vendor platform-admin console
- AI
- Advisory summaries only — OpenAI / Gemini, platform or BYOK
- Data
- Supabase PostgreSQL, tenant_id + RLS on every table
- Pricing
- Pilot · Enterprise (packaging with design partners)
The problem
The agent nobody owns, with access nobody approved.
Enterprises are deploying AI agents faster than any control can track them. Most exist as untracked service accounts.
- 1
No owner
Provisioned as SVC_FINANCEBOT_PRD by someone who has since changed teams. No business owner, no technical owner, nobody to approve a change.
- 2
Purpose that no control can read
The agent's approved scope lives in a ticket, a design doc or someone's memory — never anywhere a control can evaluate.
- 3
Access far beyond purpose
Nested groups, OAuth scopes and tool permissions add up to reach that nobody has computed, let alone certified.
- 4
Behaviour disconnected from identity
Runtime logs sit in an observability tool keyed by service name, cut off from the entitlement and approval that allowed the action.
The product
SHOULD. CAN. DID. Three views that must agree.
WonderAgent makes agents first-class enterprise identities across the IAM platforms a customer already runs — Saviynt, Okta, Entra, custom IAM and MCP runtimes map into one canonical model.
01
Identity & lifecycle
Every agent gets an owner, a purpose contract and a lifecycle state from discovered to retired. Discovery surfaces agent-like identities from connected systems; duplicates are detected and merged.
02
Effective access (CAN)
Real technical reach computed from entitlements, roles, groups, OAuth scopes and tool permissions — with access paths, so the right grant is removed rather than guessed.
03
Runtime assurance (DID)
MCP and REST event ingestion builds a per-agent timeline of tools invoked, resources touched and actions taken, correlated back to identity and compared against SHOULD and CAN.
04
Risk, certification & evidence
Deterministic scoring — never an LLM guess — for excessive access, unauthorised actions, sensitive-data violations and behavioural deviation. Certification campaigns produce auditor-ready evidence packs.
How it works
From signal to outcome.
Step 1
Connect
Import identities and access from existing IAM plus runtime events from MCP or REST sources. Connectors declare capabilities explicitly; read-only means read-only.
Step 2
Declare purpose
Name an owner, approved applications, approved data classes and approved actions. That contract becomes SHOULD.
Step 3
Compare continuously
Purpose, effective access and observed behaviour are evaluated by explicit rules. Findings carry the evidence that produced them.
Step 4
Remediate with a human
Every recommended revocation waits for a human to confirm, is recorded against the finding, and is re-evaluated once access changes.
Product tour
Desktop and mobile, one product.
Captured from the deployed product. Some views show demonstration data.
Tenant overview — counts, risk by severity, action queue
The same overview on a phone
Risks & Alerts — worst severity first
The agent inventory — owner, lifecycle, criticality
Product site on mobile
SHOULD · CAN · DID — the governance model
Capabilities, on mobile
Agent inventory, dark theme
Market & why now
Non-human identity is the fastest-growing attack surface in the enterprise.
Every enterprise IAM programme was built for people. AI agents inherit service-account sprawl, then add autonomy. Security leaders need to answer 'which agents do we run, who owns them, what can they reach, what did they do?' — and prove it to auditors.
Who buys
- Regulated enterprises in finance, healthcare and public sector
- Organisations rolling out MCP-based agent platforms
- IAM/IGA teams extending Saviynt, SailPoint, Okta or Entra to agents
- GRC teams facing AI-specific audit requirements
Why now · 1
Agent adoption is outpacing governance; MCP has standardised how agents reach tools, which makes runtime observation tractable.
Why now · 2
Regulators and auditors are asking for demonstrable control over AI systems, not policy documents.
Why now · 3
Incumbent IAM vendors are strong on human identity; a vendor-neutral layer that keeps them as system of record is the low-friction path in.
Business model
Enterprise SaaS, priced per tenant.
Multi-tenant from day one with a separate vendor-only platform-admin boundary for tenants, subscriptions, feature flags, usage and health. Deployment-ready today; commercial packaging follows the first design customers.
Pilot
Read-only proof
- Connect one IAM and one runtime source
- Discover and register agents
- First risk findings and a certification round
Enterprise
Governance in production
- Unlimited agents and integrations
- SSO/MFA, roles and permissions
- Certification campaigns and evidence packs
- Human-confirmed remediation workflows
Defensibility
What compounds.
Deterministic by architecture
No authorisation, risk, policy or remediation decision depends on a language model. AI writes advisory summaries only. That is an auditable promise competitors chasing 'AI security' cannot easily make.
Vendor-neutral canonical model
Saviynt, SailPoint, Entra, Okta, custom IAM and MCP map into one model without any becoming the internal architecture.
Built to enterprise bar from line one
Tenant RLS on every table, server-side tenant context, immutable audit, encrypted credentials, CSP headers, rate-limited auth — verified by a dedicated QA module.
Execution to date
Verifiable, not aspirational.
Pulled from the product's own public engineering trackers. Source code, trackers and live demos are available to serious parties on request.
Stories complete
139 / 165
84% across 11 modules; P0 done in every module
API surface
89 routes
84 guarded by requirePermission; the 5 exceptions documented by design
Screens
27 + 8
Customer pages plus vendor platform-admin console
Integrations
Saviynt · REST · MCP · Webhooks
Read-only by default; write capabilities must be declared
Roadmap
What comes next.
Now
- Live IdP handshake for SAML/OIDC SSO
- Email notification channel
- Rollout of design-system primitives across every screen
Next
- Point-in-time effective-access comparisons
- Scheduled certification escalation and evidence delivery
- SailPoint and Entra native connectors
Later
- Approved automation paths for low-risk remediation
- Cross-framework control mappings
- Partner and MSSP editions
The ask