Get Help

WonderAgent is an AI Identity Governance and Runtime Assurance platform. It makes every AI agent in your organization a first-class identity with an owner, an approved purpose, a known set of permissions, and an observable record of what it actually did.

It is deliberately not a replacement for your IAM, IGA, PAM or SIEM. Those remain the system of record; WonderAgent reads from them, builds a vendor-neutral picture of each agent, and tells you where approved purpose, technical capability and real behaviour disagree.

1. Create or select an organization when you first sign in. Everything in WonderAgent is scoped to that organization (tenant) — data is never shared between them.

2. Connect a source system under Integrations so WonderAgent can import the agents and permissions your IAM already knows about.

3. Review imported agents under Agents → Discovery and register the ones that matter.

4. Give each registered agent an owner and an agent contract — its approved purpose, applications, data and actions. This is what SHOULD means for that agent.

5. Open Risks & Alerts. Findings appear where an agent can do, or did, something its contract does not approve.

SHOULD comes from the agent's contract: the purpose, applications, data classes and actions you approved.

CAN is computed from IAM data — the entitlements, roles, groups, OAuth scopes and tool permissions that agent's identities actually hold. An agent frequently CAN do far more than it SHOULD.

DID comes from observed runtime activity: the tools, resources and actions the agent really used.

The product's whole value is the comparison. Access it CAN use but SHOULD not have is excessive access. Something it DID that it SHOULD not have done is a violation. The Runtime and Risk sections show these side by side.

Open an agent and edit its contract to declare what it is approved to do: business purpose, which applications it may touch, which data classes, and which actions (for example READ and REPORT but not WRITE or DELETE).

Contracts also carry autonomy and oversight fields — autonomy level, allowed tools, whether human approval is required, and what monitoring is expected.

Without a contract an agent has no SHOULD, so excessive-access and unauthorized-action findings cannot be calculated for it. Registering an agent and leaving it without a contract is the single most common reason a tenant sees no findings.

Agents → Register adds an agent manually. Most agents instead arrive through an integration and are registered from the Discovery inbox.

Every agent needs an owner: a named human accountable for it. Ownership drives certification campaigns and remediation routing, and missing ownership is flagged as a governance risk in its own right.

Agents move through lifecycle states (for example proposed, active, restricted, suspended, retired). Transitions are recorded and auditable, and a suspended agent can be restored.

After an integration syncs, WonderAgent looks for identities that behave like AI agents — service accounts, tokens and non-human identities with agent characteristics — and lists them in the Discovery inbox with the evidence behind each candidate and a confidence signal.

From there you can register a candidate as a governed agent, link it to an agent you already registered, or ignore it. Ignoring is recorded, not silent, so the same candidate does not reappear as noise.

Duplicate detection runs alongside this and proposes merges when the same real agent appears under several identities.

Integrations → New connects a source. WonderAgent ships a Saviynt read integration, a generic REST connector, and MCP runtime ingestion, plus webhook endpoints for push-style sources.

Credentials are encrypted at rest and are never returned by any API, logged, or shown back to you after saving.

A connector declares its capabilities explicitly. One configured read-only cannot perform writes or remediation — that boundary is enforced, not merely documented.

Sync runs appear under Integrations → Jobs with their status and any errors, so a failed import is visible rather than silent.

Access shows each agent's computed capability: entitlements, application roles, groups, OAuth scopes and tool permissions, resolved across every identity that agent owns.

Access paths matter as much as the totals. WonderAgent shows how a permission was granted — directly, through a role, through nested group membership, or through delegation — so you can remove the right grant rather than guessing.

This is the CAN half of the model, and it is computed from imported IAM data rather than asserted by hand.

Where a contract is per-agent, a policy applies across agents — for example forbidding any agent from holding write access to a production financial system, or requiring human approval for a class of action.

Policy evaluation is deterministic. No policy decision in WonderAgent depends on a language model.

Violations surface as findings in Risks & Alerts alongside contract-based findings.

Runtime events arrive from MCP runtime observation and other configured sources, and build a timeline per agent of tools invoked, resources touched and actions taken.

The comparison view puts SHOULD, CAN and DID next to each other for one agent, which is usually the fastest way to explain a finding to someone who did not configure the agent.

Activity WonderAgent cannot attribute to a governed agent is itself signal, and feeds discovery rather than being discarded.

Risks & Alerts lists open findings with a severity, the agent involved, and the evidence that produced them. Every finding can be traced back to the specific access or event behind it.

Risk scoring is deterministic and rule-driven. A language model never decides a severity or produces a finding — that is an architectural rule, not a configuration choice.

Findings carry a recommended remediation, but consequential changes (revoking access, suspending an agent) require a human to initiate them.

Re-evaluation closes the loop: once the underlying access or behaviour changes, the finding is re-checked and resolved if it no longer holds.

A single finding rarely means an agent is rogue. The rogue view aggregates the signals for one agent so a pattern is visible: acting outside its contract, holding access nobody approved, or having no accountable owner.

Use it to prioritize. It answers 'which agent should I look at first' rather than 'what is technically wrong here'.

Compliance → Campaigns launches a certification round. Each item pairs an agent's access with the risk and usage evidence a reviewer needs, so decisions are informed rather than rubber-stamped.

Reviewers keep, flag or revoke. Every decision is recorded with who made it, when, and on what evidence.

Overdue items escalate automatically, and the campaign produces an evidence pack suitable for handing to an auditor.

Audit records actor, tenant, target, action, timestamp and outcome for every security-sensitive operation, and is designed to be read as evidence rather than as debug logging.

Reports produce exportable governance evidence, including a governance evidence pack as PDF and CSV exports of underlying data.

Search covers agents, findings and policies from one box, scoped to your organization.

Settings → Notifications controls which events reach you. In-app notification always works; email delivery additionally requires the deployment to have an email provider configured.

If email is not configured, notifications still appear in-app rather than failing — you simply do not get the mail copy.

Built-in roles range from a full tenant super administrator down to read-only and requester roles that can see agents but not policies.

Permissions are checked server-side on every route and action — the UI hides what you cannot do, but the enforcement is not the hiding.

Platform administration is a separate boundary entirely. It belongs to the vendor operating WonderAgent and is never reachable by a customer role, no matter how privileged.

Password sign-in, Google sign-in and domain-based SSO are all available from the sign-in screen. SSO routes users whose email domain has an active connection to their identity provider.

Forgot your password? Use the 'Forgot password?' link on the sign-in screen; the emailed link lets you set a new one.

Sessions end after a period of inactivity and after an absolute lifetime regardless of activity. Logging out is global by design — it ends your other sessions too.

Settings → SSO configures connections and just-in-time role mapping; Settings → Security covers the remaining organization-level security options.

AI in WonderAgent writes prose summaries of data that has already been computed. It never makes an authorization, risk, policy or remediation decision — those are always deterministic.

Settings → AI selects the provider and, optionally, your own API key. If you do not bring a key, the platform-wide default key is used when the deployment has one configured.

If neither exists, AI features say so and tell you how to fix it rather than failing silently. Setting the platform default is currently a deployment environment-variable change; there is no platform admin screen for it yet.

You can belong to more than one organization and switch between them; what you see is always scoped to the active one.

Isolation is enforced by row-level security in the database, not only by application code, so an application bug cannot leak another organization's rows.

This applies everywhere, including caches, search indexes, exports and anything sent to an AI provider.

The usual cause is agents without contracts. With no approved purpose recorded there is no SHOULD, so excessive-access and unauthorized-action checks have nothing to compare against.

The other common cause is no imported data yet — check Integrations → Jobs to confirm a sync actually completed rather than failing.

WonderAgent recommends remediation and can hand it to your IAM workflow, but a human initiates consequential grants, revocations, policy overrides and destructive actions.

This is deliberate. An autonomous system that silently revokes production access is a bigger risk than the one it is trying to manage.

Every score and finding comes from explicit rules you can trace. AI output is labelled advisory and is never read back into a decision.

That means turning AI off changes what the product explains, never what it decides.