Core Concepts

MITRITY governs autonomous AI agents in real-time. To use the platform effectively, it helps to understand the core abstractions that underpin how governance decisions are made. This page covers the five foundational concepts: 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

In MITRITY, you register each agent with a name, description, and mission scope. The platform does not require changes to your agent's code. Instead, a governance binary deployed alongside the agent intercepts and validates its actions.

Every agent gets a unique Agent ID used to track its actions, enforce policies, and build behavioral models over time. Agents can be grouped by team, environment, or purpose for bulk policy assignment. Each agent includes built-in edge identity — platform, region, version, and heartbeat status — so governance and deployment are managed through a single resource.

Governance Runtime

The enforcement layer runs as a lightweight binary deployed alongside your agents. It ships as two purpose-built binaries: Mitrity Gateway (a governed MCP server with tool aggregation and credential isolation) and Mitrity MCP Sidecar (a lightweight stdio wrapper for MCP protocol governance). See Integration Modes for details.

Key characteristics:

• Binary size: ~2MB compiled Go binary
• Memory footprint: ~50MB at steady state
• Decision latency: <0.5ms per action (local ML inference)
• Deployment: Docker container, standalone binary, systemd service, or Cloud Run

The governance binary connects to the MITRITY control plane via gRPC, receiving policy updates and ML model weights in real-time. When it cannot reach the control plane, it continues operating with its last-known policies and models. You configure whether it defaults to fail-open (allow actions) or fail-closed (block actions) during disconnection.

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 behavioral patterns that are expected.

A mission profile includes:

• Allowed actions: The set of operations the agent is permitted to 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: Expected volume of actions per time window
• Interaction patterns: Which other agents or services this agent normally communicates with

Mission profiles serve as the baseline for both policy enforcement and behavioral analysis. When an agent's actions deviate from its mission profile, the platform detects the drift and responds according to your enforcement mode.

Policies

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

• Type: allow, deny, alert, or hold
• Action pattern: A glob or regex pattern matching action types (e.g., read_*, bulk_export_*)
• Priority: Higher-priority policies are evaluated first
• Constraints: Optional conditions such as time-of-day, rate limits, or source agent

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

Policies can be created in the dashboard, managed via the API, or defined as code and applied through CI/CD pipelines. See writing policies for the full policy language and examples.

Behavioral Hash

A Behavioral Hash is a compact fingerprint of an agent's action sequences over a rolling time window. Rather than evaluating individual actions in isolation, the behavioral hash captures the pattern of behavior — what actions an agent takes, in what order, at what frequency, and to which resources.

The hash is computed by the local DriftGuard model and compared against the agent's established baseline. This allows the platform to detect:

• Sequence anomalies: An agent performing actions in an unusual order
• Frequency anomalies: Sudden spikes in action volume
• Resource anomalies: Accessing resources outside the normal pattern
• Temporal anomalies: Operating outside expected time windows

The behavioral hash changes when an agent's behavior deviates from its baseline. Small changes (e.g., a new but related action) produce a minor hash delta. Large changes (e.g., accessing an entirely new resource category) produce a significant delta that triggers a drift alert.

Drift Score

The Drift Score is a continuous value between 0 and 1 that measures how far an agent's current behavior has deviated from its established baseline.

• 0.0: Behavior perfectly matches the baseline — no deviation detected
• 0.0 - 0.3: Normal operational variance, no action required
• 0.3 - 0.6: Moderate drift, may warrant investigation
• 0.6 - 0.8: Significant drift, likely requires attention
• 0.8 - 1.0: Severe drift, potential unauthorized behavior

The drift score is computed by the control plane's centralized ML models, which combine multiple signals:

• The behavioral hash delta from the local DriftGuard model
• Action-level anomaly scores from DeepTrace, the sequence analysis model
• Relationship anomalies from TrustGraph, which maps agents, users, resources, and roles
• Mission profile deviation — how far actions stray from the declared scope

Drift scores are visible in the dashboard on each agent's detail page and in the audit log. You can configure alert thresholds per agent or tenant: for example, alert at 0.5 and block at 0.8. The platform continuously recalibrates baselines as agents learn and evolve, so drift scores reflect genuine anomalies rather than normal operational changes.

How it all fits together

When an agent performs an action:

1. The Mitrity Gateway intercepts the action before it executes
2. Policies are evaluated in priority order for an immediate allow/deny/alert/hold decision
3. The Behavioral Hash is updated with the new action sequence
4. The Drift Score is recalculated based on the updated hash and other signals
5. If the drift score exceeds thresholds, additional alerts or enforcement actions are triggered
6. The event — including the decision, drift score, and contributing factors — is logged and forwarded to the dashboard, audit log, and any configured SIEM integrations

This layered approach means you get both deterministic policy enforcement (rules you define) and adaptive behavioral analysis (ML-driven anomaly detection) working together on every action.