New: Agent approvals, red teaming and model scanning. See how
MITRITY
The platform

One runtime, one set of policies and one audit trail.

Every tool call, API request and database query your own agents make goes through the Mitrity runtime. Each one is checked against what you said the agent is for, in real time, before it runs. Agents that live inside SaaS platforms join the same record through read-only connectors. Here is the whole platform, pillar by pillar.

Your side
Agent acts
any framework
Mitrity
Intercept
the Mitrity Runtime
Mitrity
Score intent
<0.5ms · DriftGuard
Mitrity
Decision
allow · hold · block
Yours to keep
Receipt
signed, hash-chained
Govern

Decide which agents may run, and keep the evidence.

Approvals, compliance posture and an inventory of what your agents use. All of it is built from the same record Mitrity keeps as it checks every action.

PILLAR 01 — GOVERNANCE & APPROVALS

Approve every agent before it runs

People keep two decisions: whether an agent may run at all, and whether a risky action may go ahead. A review shows what an agent was supposed to do next to what it actually did. One setting decides whether an agent nobody has approved can act.

  • Lifecycle statuses from proposed to approved, blocked or retired, with every change on the audit trail
  • Assessments pre-filled from what the agent did in the last 90 days, with the evidence for each answer
  • Reviews that people attest to, with separation of duties, regular re-reviews, and a change review when a finding or policy drift calls for one
  • An approval gate in the runtime that can refuse every action from an agent nobody has approved
PILLAR 02 — COMPLIANCE & EVIDENCE

Evidence your auditor can check for themselves

There are control libraries for the EU AI Act, NIST AI RMF, ISO/IEC 42001, ISO/IEC 27001, GDPR, SOC 2, OWASP Top 10 for LLM Applications 2025 and MITRE ATLAS. Mitrity works out where you stand on each one, control by control, from the records it already holds, and names every gap. Reports, evidence bundles and the audit trail behind them carry hashes and signatures that show whether anything was changed.

  • Where you stand on each library, control by control: covered, partial, not covered or not assessed, never just a percentage
  • An AI risk register with owners that shows the residual risk Mitrity computes next to the one you declared, plus AI policy statements people attest to
  • SOC 2, GDPR, ISO 27001, AI assessment and framework reports with integrity hashes, plus evidence bundles and share links that expire
  • A tamper-evident audit trail, with every event hash-chained, sealed by signed checkpoints and verifiable offline
PILLAR 03 — AIBOM

A live list of everything your agents use

The AI Bill of Materials lists every agent, tool, model, credential and connector in your environment. It isn't a spreadsheet someone updates once a quarter. It's a graph that changes as your fleet changes.

  • Agents, tools, credentials and connectors discovered automatically
  • Always current: the inventory updates with every governed event
  • Spot shadow agents, unused tools and long-lived credentials at a glance
  • Models too: the repositories your agents load are scanned, and the hosted models they call are checked against your policies
Secure

Defend every action, then test that the defense holds.

Runtime defense sits in front of your tools and model providers. Adversarial tests probe your own agents, and scans check the models they load.

PILLAR 04 — LLM GATEWAY

One governed entry point for every model and tool

The gateway sits in front of everything your agents talk to, from internal tools to the model providers they call. Permissions don't end up scattered across config files. You grant each capability in one place, and you take it back in the same place.

  • Access control for each agent and each tool: which operations are allowed, with which scopes, and when
  • Destination allowlists, so agents only reach endpoints you've approved
  • Rate limits for each tool and each agent, so even allowed actions can't be abused
  • Calls to Anthropic, OpenAI, Azure OpenAI / AI Foundry, Google Vertex AI, Amazon Bedrock (OpenAI-compatible API) or any OpenAI-compatible host, all governed the same way
  • Model allowlists, token caps, budgets and rate limits set per policy, and enforced before a call reaches the provider
PILLAR 05 — RED TEAMING

Know what someone could make your agents do

Mitrity runs adversarial campaigns against your LLM routes and your own agent endpoints, on a schedule. Each attempt is checked like any other action, and the full exchange stays in your environment.

  • Campaigns against LLM routes and your own agent endpoints, as a dry run by default, with caps on attempts, time, tokens and spend
  • Every attempt governed and audited, with full prompts and responses kept in your environment; only hashes and a redacted excerpt leave it
  • Deterministic oracles where the outcome is a plain fact, and every finding labeled with the confidence of the oracle that decided it
  • Findings mapped to OWASP Top 10 for LLM Applications 2025, MITRE ATLAS, NIST AI RMF, the EU AI Act and ISO/IEC 42001, plus a guardrail assurance score for each agent
PILLAR 06 — MODEL SCANNING

Read the model before your agent loads it

A PyTorch checkpoint is a pickle stream, and loading a pickle runs whatever code it points to. Mitrity reads the repositories your agents load without running anything, and tells you what's inside, down to the byte offset.

  • Pickle streams and PyTorch archives are taken apart, never executed, and every global they reach is listed with its byte offset
  • Header checks for safetensors and GGUF files, and a search for hidden instructions in model cards, configs and chat templates
  • A flag on anything that would run remote code (auto_map, custom pipelines, shipped Python) and on unpinned revisions
  • Hosted models seen at the gateway are checked against your policy rules and a curated list of models known to be unsafe
PILLAR 07 — INJECTION DETECTION

Three layers between attackers and your agents

Prompt injection tricks an agent into using its own access on someone else's behalf. Mitrity screens inputs before they reach the agent, with defenses that don't rely on having seen the exact trick before.

  • Layer 1: pattern matching against known injection signatures
  • Layer 2: statistical analysis that flags inputs with a suspicious structure
  • Layer 3: an ML classifier for new and disguised attempts
  • Catches attempts to override instructions, inject a system prompt or slip past filters with encoding tricks
PILLAR 08 — CREDENTIAL BROKER

Agents borrow credentials for a short time. They never own them.

A permanent API key pasted into an agent's config is like a spare key under the doormat. The broker hands out short leases at the moment they're needed instead, and only to the agents you've granted access.

  • Credentials issued just in time, on short leases
  • Remove a grant, and the agent stops getting that credential within a minute
  • Stored in the Mitrity vault, encrypted with a key for your organization alone
  • No keys in agent configs, so there's no standing secret there to steal
PILLAR 09 — DELEGATION GOVERNANCE

When agents hand work to other agents, the chain matters

A compromised agent with little access shouldn't be able to get a more powerful agent to do its work. Mitrity tracks every chain of agent-to-agent delegation, and access can only get narrower further down the chain.

  • Every delegation chain tracked across your multi-agent workflows
  • Detection of circular delegation, plus limits on depth and fan-out
  • Privileges pass down by intersection, so a delegate never has more access than its caller
  • AI-to-AI privilege escalation is blocked as it happens, not discovered in a post-mortem
PILLAR 10 — DATA LOSS PREVENTION

Sensitive data stays where it belongs

Agents touch the most sensitive data you have. Mitrity recognizes it as it moves, redacts or blocks it before it leaves, and stops it from going to destinations you never approved.

  • Classification in flight: personal data, credentials, financial and health data
  • Blocks data from going out to destinations nobody authorized
  • Accumulation detection stops data from being taken a little at a time across sessions
  • Prompts are redacted before they leave your cluster, and model responses before they reach the agent
PILLAR 11 — THREAT INTELLIGENCE

Attacks seen elsewhere help protect you

Traditional threat intel is mostly IP addresses and file hashes. Attacks on agents look different, so Mitrity shares behavioral attack signatures across all its customers. No customer's data ever leaves its own boundary.

  • Threat indicators from the community, contributed anonymously
  • Pattern detection across customers, with strict privacy guarantees
  • Everyone gets the same indicators, but a match is only ever seen by the customer it happened to
  • Defense against new attacks that gets better with every customer
Agents inside SaaS

Reach the agents that live inside your SaaS

Some agents never pass through a gateway. They run inside Microsoft 365, Salesforce, GitHub and Snowflake. For those agents, Mitrity provides AI Security Posture Management (AI-SPM). You connect each platform with read-only credentials that you create, and Mitrity governs the agents from the outside: it finds them, shows what they did, checks their security posture and puts them through the same reviews as the rest of your fleet. Nothing gets installed in the vendor's cloud.

  • GitHub Copilot: find coding agents, import the org's audit activity, read its security posture
  • Microsoft 365 Copilot and Copilot Studio: the tenant's Copilot, its published agents and every Copilot Studio agent, with posture checked read-only
  • Salesforce Agentforce: Agentforce agents, setup audit telemetry and indicators of the org's posture
  • Snowflake Cortex Agents: find Cortex Agents, import AI observability activity, read the account's security posture
  • Read-only AI-SPM (Discover · Observe · Posture) on Pro and Enterprise, with nothing to install
The foundation

Every pillar stands on intent-aware governance.

Mitrity looks at more than what an agent does. It checks whether each action fits what the agent is for. Models that run where your agents run score every action for drift, risk and anomalies.

DriftGuardScores each action against what the agent is for, looking at drift, risk and anomalies. It runs locally, in the Mitrity Runtime.
DeepTraceModels in the control plane that connect events across sessions, agents and time, to catch what no single event shows.
TrustGraphA live graph of agents, credentials and delegation paths. It flags a relationship that has never existed before.
ColdStartUseful behavioral baselines from the first event, so you don't spend weeks in learning mode before you can enforce.
NarratorExplains each audit event in plain language, with the factors behind the decision, so anyone on your team can follow what happened.
Run it your way

Enforcement that fits how your team works.

Enforcement modes

Monitor → Alert → Enforce

Move each agent along at your own pace. Start by watching, switch on alerts, then let Mitrity block. You choose whether it fails open or fails closed.

Human in the loop

Approvals in Slack

A suspicious action waits for a person, who sees the full context and can approve or deny it right there. Timeouts are configurable, so an agent is never stuck waiting forever.

Your security stack

Native SIEM forwarding

Every decision Mitrity makes on an agent action is sent to Splunk (HEC), a CEF endpoint over HTTPS or any webhook. Your SOC keeps working in the console it already uses, now with better signal from your agents.

<0.5ms
decision latency, locally at the edge
10M+
agent decisions governed per day
99.99%
platform uptime SLA
0
undetected rogue actions
See it yourself

Put the whole platform on your agents in five minutes.

Start with the pillars you need today. Turn on the rest as your fleet grows, and what you've already set up carries over: what each agent is for, its decisions and its audit trail.