Core Concepts

MITRITY governs autonomous AI agents in real time. This page explains five concepts you meet in its governance decisions and audit events, so you know what you are setting up: Agents, Mission Profiles, Policies, Behavioral Hashes and Drift Scores.

Agents

An agent is any autonomous software that takes actions on behalf of your organization. This includes:

• LLM-powered assistants that call tools and APIs
• Multi-agent pipelines and orchestration frameworks
• MCP-based agents using Model Context Protocol tool calls
• Custom automation scripts that interact with databases, cloud APIs or third-party services
• SaaS-embedded agents that run inside a vendor's cloud, such as the GitHub Copilot coding agent, Microsoft 365 Copilot and Salesforce Agentforce

You register each agent in MITRITY with a name, a description and a mission scope. You don't need to change your agent's code. Instead, a governance binary deployed alongside the agent intercepts and validates its actions.

There are two exceptions to this model. Know both before you rely on it:

• SaaS-embedded agents run in the vendor's cloud, so they cannot be sidecarred at all. MITRITY reaches them through read-only platform connectors. The connectors discover these agents and observe their activity without an edge binary in the loop.
• Framework built-in execution tools sit inside an agent you can sidecar, but outside the path the sidecar sees. Examples are Claude Code's Bash, LangChain's ShellTool and CrewAI's code interpreter. A shell, code interpreter or file writer that the agent's framework provides runs in the agent process and never produces an MCP tool call, so the governance binary does not see it through MCP.

On Claude Code and the Claude Agent SDK, mitrity-hook closes the built-in tool gap (edge release v0.20). It is a PreToolUse hook: before each built-in tool runs, it asks the edge's loopback admission API for a decision. The call goes through the same pipeline and the same audit trail as an MCP call, marked surface=agent_hook. With every other framework, disable those tools or treat them as ungoverned. Governance Coverage lists the exact setting for each framework and the states the coverage badge reports.

Every agent gets a unique Agent ID. MITRITY uses it to track the agent's actions, enforce policies and build behavioral models over time. You can group agents by team, environment or purpose to assign policies in bulk. Each agent reports its platform, region, version and heartbeat status, so you manage governance and deployment through a single resource.

Governance Runtime

The enforcement layer runs at one of four governance surfaces. All four use the same MITRITY decision engine:

• Mitrity Gateway, a governed MCP server with tool aggregation and credential isolation. It is a lightweight binary deployed alongside your agents. See Integration Modes.
• Mitrity MCP Sidecar, a lightweight stdio wrapper for MCP protocol governance. It is also deployed alongside your agents. See Integration Modes.
• Mitrity Mesh Authorizer, which applies the same engine at an Istio service-mesh decision point. It resolves each request's SPIFFE identity to the calling agent. See Mesh Enforcement (Istio).
• Mitrity LLM Gateway, a TLS-terminating egress gateway. Agents point their LLM provider base_url at it. It governs prompts and model responses, and it redacts data in the traffic itself, on the wire. See Mitrity LLM Gateway.

Whichever surface enforces a request, governance and audit come together in the same control plane.

Key characteristics:

• Decisions: made locally, in the action's path, before the action runs. The local ML step (DriftGuard) runs only when the binary runs with ml.enabled, which is off by default
• Deployment: a local process launched over stdio by the agent's MCP client, on the host or inside the agent's own container or pod
• Resources: see the system requirements in the deployment guide

The governance binary talks to the MITRITY control plane over HTTPS, through a REST API, and authenticates with the agent key in the X-Agent-Key header:

• It sends a heartbeat when it starts, and then every 30 seconds. Each heartbeat reply carries any updated policies and revoked agents.
• When local ML inference is enabled (ml.enabled, off by default), the reply also announces new model versions. The binary downloads each one from a signed URL, checks its SHA-256 hash and swaps it in.
• It fetches an agent's policy on demand, and caches it for cache.profile_ttl (5 minutes by default). Past that, it keeps using the cached policy while it fetches a fresh one.

When it cannot reach the control plane, it keeps enforcing its last-known policies with its last-known models, for as long as the outage lasts.

A policy's fail mode decides only the actions that need an answer from the control plane: a hold whose approval cannot be opened or followed, and a delegation hop whose chain cannot be checked.

• fail-open: those actions go ahead;
• fail-closed: those actions are refused.

See Fail modes.

Mission Profiles

A mission profile is the contract between your organization and an agent. It defines what the agent is allowed to do: its intended purpose, the resources it can access, and the behavior you expect from it.

A mission profile includes:

• Allowed actions: the operations the agent may perform (e.g., read_crm_contact, send_email, update_deal_stage)
• Resource scope: which databases, APIs and services the agent should access
• Temporal constraints: when the agent is expected to operate (e.g., business hours only)
• Rate boundaries: the expected volume of actions per time window
• Interaction patterns: which other agents or services this agent normally communicates with

Mission profiles are the baseline for policy enforcement. When an agent's actions fall outside its mission profile, the platform responds according to your enforcement mode.

Policies

Policies are the rules MITRITY evaluates on every action. They are the declarative layer that decides what happens when an agent attempts an operation. Each policy specifies:

• Type: allow, deny, alert or hold
• Action pattern: a glob or regex pattern that matches action types (e.g., read_*, bulk_export_*)
• Priority: higher-priority policies are evaluated first
• Constraints: optional conditions on the action's arguments: paths, resolved commands, domains, models. Time of day, rate and calling agent are not constraints; writing policies says what to use instead

Policies are evaluated in priority order, and the first matching policy decides the outcome. If no policy matches, the platform falls back to the default enforcement mode configured for the agent or tenant.

You can create policies in the dashboard, manage them through the API, or define them as code and apply them through CI/CD pipelines. See writing policies for the full policy language and examples.

Behavioral Hash

A behavioral hash is a fingerprint of one action. The edge computes it for every action it decides: a SHA-256 over four fields of the action, each lowercased and trimmed:

• the agent's ID;
• the action type, for example mcp:fs__read_file;
• the target, such as the tool's name on MCP surfaces;
• the parameters, sorted by name, as name=value pairs.

The same agent taking the same action with the same arguments always produces the same hash, and any difference produces an unrelated hash. The hash therefore tells you whether two actions were identical. It does not measure how different they are.

Every audit event carries its action's hash in behavioral_hash, and a behavioral_hash threat indicator matches it exactly.

Drift Score

The drift score is a number from 0 to 1 on each audit event. It says how unusual the action looked. Where it comes from depends on the kind of agent:

• Runtime agents: the edge computes it with its local ML model, DriftGuard, when the edge runs with ml.enabled (off by default) and a model loaded. The model reads a sliding window of the most recent actions (ml.buffer_size, 256 by default), each encoded from its action type, its target and the time since the agent's previous action, and returns an anomaly score from 0 to 1. Until the window is full, and whenever ML is off, the drift score is 0.
• SaaS-embedded agents: the connector scores each imported event that belongs to an agent with a fixed heuristic. An event type the agent has not shown in the last 30 days scores 0.75, or 0.90 if the agent also has 30 or more events within the last hour. Thirty or more events within the hour alone score 0.72, and anything else scores 0.20. An agent with no history yet has no new event types.

Where the drift score is used:

• DriftGuard, a policy feature, compares a runtime agent's drift score with the policy's drift threshold (0.7 by default). Above it, Enforce blocks the action, and Log records the detection and lets the action through.
• With behavioral drift alerts on, a runtime agent's event whose drift score reaches your Drift Score Threshold (0.7 by default) sends a notification.
• Insights and compliance reports count an event with a drift score above 0.5 as an anomaly, and average drift scores per agent and per day.

You see each event's drift score in the Audit Log's Drift column. ML Insights covers the averages and trends.

How it all fits together

When an agent performs an action:

1. The Mitrity Gateway intercepts the action before it executes.
2. The edge computes the action's behavioral hash.
3. Policies are evaluated in priority order for an immediate allow, deny, alert or hold decision.
4. When the edge runs with ml.enabled, DriftGuard scores the action, and the policy's DriftGuard feature blocks or logs it if the drift score is above the threshold.
5. The event is logged and forwarded to the dashboard, the audit log and any configured SIEM integrations. It includes the decision, the behavioral hash and the drift score.

Every action gets deterministic policy enforcement, from the rules you define. When ML is on, it also gets an anomaly score from DriftGuard.