AI risk management software for systems that act
Model risk management assesses outputs. Agentic risk is about authority: what an agent can reach, what it can irreversibly change, and whether a control exists that can stop it. Software that measures the second kind.
The problem
What this is actually about
Risk software written for models measures what models do wrong: accuracy, drift, bias, disclosure. Those measurements stay valid and stop being sufficient the moment the system holds a credential, because the exposure is then a function of permissions rather than of prediction quality.
The practical difficulty is that authority is invisible in the places risk is usually assessed. A questionnaire records what an agent was designed to do; the risk is what it can currently reach. Those two diverge quietly, and the gap between them is the finding.
What the platform does about it
Read from the product architecture rather than written here, so this page cannot promise something no module ships.
What AI agents exist here?
- Connectors across AI platforms, cloud, identity providers, source control, enterprise applications and infrastructure
- Shadow agent discovery from model API traffic, AI keys, MCP configuration, SDK dependencies and automation credentials
- An inventory record per agent: owner, purpose, model, framework, tools, MCP servers, data sources, permissions and secrets
- Ten lifecycle statuses from Discovered through Quarantined and Retired
What is this agent allowed to reach?
- Role and attribute rules evaluated with agent, user, tenant, data, tool, environment, time, risk and declared purpose in context
- Action-level permissions, so reading a supplier and changing its bank details are separate grants
- Five sensitive action classes from read through draft, reversible execution, human approval and dual approval
- Just-in-time privileges that are issued for one action and expire rather than accumulating
- A credential broker that issues scoped, short-lived secrets on request, so an agent never holds a permanent key
Has it been tested, and is it still the version we approved?
- Security tests for prompt injection, privilege escalation, data leakage and unsafe external calls
- Permission tests that try to exceed the role and cross the tenant boundary
- Tool behaviour tests for dangerous calls the task never required
- Regression testing between agent versions
- Certification from development through internal, approved, production and high-risk
- Recertification when the model, prompt, tools, MCP servers, permissions, data sources or owner change
Can we prove any of this to an auditor?
- Mapping to NIST AI RMF, ISO 42001, SOC 2 controls and internal AI policy
- Control evidence computed from live state rather than asserted
- Continuous monitoring of ownership, permission reviews, approved models, incidents and certification status
- A generated audit package covering inventory, owners, permissions, approvals, testing, policies, incidents and access reviews
- An optional customer-facing trust centre that publishes the programme without exposing infrastructure
What it leaves behind
The artefacts these modules produce. Evidence generated by a decision, rather than assembled for an audit afterwards.
- A first-day discovery report naming agents nobody had registered
- An unregistered-agent alert with provider, data reach and risk
- A permission inventory showing where an agent exceeds its purpose
- An expiry on every elevated grant
- A credential ledger: which agent held what, against which system, and when it lapsed
- A certification record per agent version
- A diff between versions with the resulting risk change
- A control-by-control coverage figure with the gap named
- An audit package generated on demand
See it working
Every claim above has somewhere on this site you can go and check it.
- A score broken into its factors
Every risk number decomposed into the facts that produced it, so a disagreement is about a fact rather than a verdict.
- How the score is defined
The scoring model as a written specification rather than a proprietary black box.
- Testing an agent before production
What the assurance probes cover, and what they cannot see without the agent runtime.
Common questions
- How is agentic AI risk management different?
- The unit of analysis changes. Instead of assessing a model’s outputs you assess an agent’s authority: the tools it can call, the data it can reach, which of its actions are irreversible, who it acts on behalf of, and what happens when it delegates.
- Can anomaly detection manage the risk on its own?
- No. Anomaly scoring is useful for deciding what to look at next. Irreversible actions need deterministic policy that does not depend on a model judging intent correctly, because the cases a detector misses are the ones an attacker constructs.
- What about agents inside vendor SaaS products?
- Ask which vendor agents hold credentials in your tenant, what those credentials can reach, whether their actions appear in your audit trail, and whether you can revoke them without ending the vendor relationship.