NIST Framework Alignment
MIR's progressive authorization architecture maps directly to NIST Zero Trust, AI Risk Management, and cybersecurity control frameworks
Last updated: February 2026
MIR is not a compliance product. MIR is behavioral trust infrastructure. But the architectural decisions that make MIR work — continuous verification, earned trust tiers, least-privilege authorization, and immutable audit trails — are the same principles that underpin NIST's governance frameworks.
800-207 Zero Trust Architecture
NIST Special Publication 800-207 defines Zero Trust as an architecture where no entity is trusted by default, access decisions are made per-request, and trust is continuously evaluated. MIR implements these principles as runtime infrastructure.
Never trust, always verify
Every MIR policy evaluation starts from zero. There is no cached "trusted" state that persists between requests. Each call to the Policy API resolves the actor's current behavioral signals — event count, cross-organization history, recency, consistency — and produces a fresh decision.
Least-privilege, per-request
MIR decisions are not binary allow/deny. The Policy API returns one of four outcomes — allow, step_up, limit, or deny — scoping access to the minimum appropriate for the actor's demonstrated trust level. An actor with thin history might be allowed to proceed but with row limits on data export or rate constraints on API calls.
Earned trust, not assumed trust
MIR's tier model (Tier 0 through Tier 3) is a direct implementation of continuous trust evaluation. Tier is not assigned by an administrator. It is computed from behavioral signals: volume of verified events, number of distinct organizations that have corroborated the actor's participation, how long ago activity began, and how consistently it has continued.
| 800-207 Tenet | MIR Implementation |
|---|---|
| All data sources and computing services are considered resources | Every action in the registry is a protected resource with its own tier requirement |
| Access is granted on a per-session basis | Policy evaluation is per-request, not per-session |
| Access is determined by dynamic policy | Decisions computed from real-time behavioral signals + configurable action rules |
| Enterprise monitors and measures security posture | Every evaluation produces an audit record with tier, decision, signals, and risk factors |
| Authentication and authorization are dynamic and strictly enforced | Trust tier can change between consecutive requests as new events are ingested |
AI 100-1 AI Risk Management Framework
The NIST AI RMF provides a structured approach to managing risk in AI systems through four functions: Govern, Map, Measure, and Manage. As organizations deploy AI agents that take autonomous action, MIR provides the trust infrastructure these functions require.
GOVERN — Establish accountability
MIR's Policy API gives organizations a governance layer for AI agent actions. Rather than granting agents blanket access, each action is evaluated against the agent's behavioral history. Organizations define which actions require which trust tiers, what step-up requirements apply, and how to handle agents with insufficient history.
MAP — Contextualize risk
MIR resolves behavioral signals that contextualize risk at decision time: How many verified events has this actor produced? Across how many organizations? How recently? How consistently? These signals map risk without requiring organizations to build their own behavioral baselines from scratch.
MEASURE — Quantify trust
MIR's tier system (0–3) is a quantified trust measurement. It is computed from observable signals, not subjective assessment. Every policy evaluation logs the tier used, the signals that produced it, and the decision that resulted — creating a measurable, auditable record of trust over time.
MANAGE — Act on risk in real time
The four-outcome decision model (allow / step_up / limit / deny) is risk management at the point of action. When an agent's trust level is insufficient for the requested action, MIR doesn't just block it — it returns actionable guidance: what step-up is required, what limits apply, or why access was denied. Organizations can configure per-action rules, rate limits, and fail-open or fail-closed behavior.
| AI RMF Function | MIR Capability |
|---|---|
| GOVERN 1.1 — Legal and regulatory requirements identified | Per-partner action registry with configurable tier requirements and override rules |
| MAP 1.1 — Intended purpose and context documented | Action definitions with category, sensitivity, and resource type classification |
| MEASURE 2.1 — Evaluations performed for trustworthiness | Real-time trust tier computation from behavioral signals |
| MANAGE 1.1 — Risk treatment decisions implemented | Progressive authorization: allow, step_up, limit, or deny per action |
| MANAGE 2.1 — Risks addressed based on impact | Tier-scaled limits (rate, row count, byte size) proportional to trust level |
| MANAGE 4.1 — Incidents documented and managed | Complete audit trail with evaluation ID, actor, decision, signals, and timestamp |
800-53 Security and Privacy Controls
NIST 800-53 defines the catalog of security controls used across federal systems and increasingly adopted by private-sector organizations. MIR's architecture addresses several control families directly.
| Control Family | Control | MIR Implementation |
|---|---|---|
| AC | Access Control | Tier-based, per-action authorization with progressive step-up requirements |
| AU | Audit & Accountability | Immutable audit log for every policy evaluation: actor, action, decision, tier, signals |
| IA | Identification & Authentication | Cryptographic identity linking (SHA-256 hashed), API key authentication, SSO integration |
| RA | Risk Assessment | Real-time risk signals: event density, recency, consistency, cross-org corroboration |
| SI | System & Information Integrity | Event validation, velocity limiting, quarantine for suspicious activity surges |
| SC | System & Communications Protection | TLS-only transport, org-scoped data isolation, no cross-tenant data leakage |
CSF 2.0 Cybersecurity Framework
The NIST Cybersecurity Framework organizes security functions into six categories. MIR contributes to four of them.
| CSF Function | MIR Contribution |
|---|---|
| Govern | Configurable action registry with per-partner override rules, role-based dashboard access, organizational controls for policy management |
| Identify | Behavioral baselines computed from event history; actor trust tier quantifies risk posture |
| Protect | Progressive authorization gates every action; tier-scaled rate limits and transaction constraints enforce least privilege |
| Detect | Behavioral signals surface anomalies: new actors, unusual velocity, inconsistent patterns, thin cross-org history |
What Makes MIR Different
Most governance frameworks assume trust is established within a single organization. MIR computes trust from cross-organizational behavioral signals — verified participation history that spans multiple independent organizations.
When an actor has demonstrated consistent, verified behavior across three organizations over six months, that signal is fundamentally stronger than anything a single organization can establish on its own. MIR makes this federated trust computable and actionable at the point of every access decision.
- Trust tiers computed from cross-org event history, not self-reported attributes
- No organization sees another organization's raw data — only the computed trust signal
- Portable trust: an actor's history follows them across organizations without re-establishing baselines
- Organizations configure their own action requirements and override rules against shared trust signals
Ready to align your agent governance with NIST?
MIR provides the behavioral trust infrastructure. Your organization defines the policy rules.