How MIR Works for Enterprises

The Problem at Decision Time

Every authorization stack answers two questions: who you are, and what you can do. Neither answers whether the entity in front of the system has demonstrated the standing to perform this specific action, right now, at this scale.

When an AI agent shows up with valid credentials, allowed policy, and an authorized API path, the existing identity-and-authorization stack cannot distinguish it from a legitimate operator. The 2026 CrowdStrike Global Threat Report finding -- 82% of detected intrusions used no malware -- is the same point at scale: the threat is credentialed, authorized, and indistinguishable from normal activity at the credential layer.

That evidence has to live outside the consuming system, in a form a third party can verify, queryable in milliseconds, before the action commits. That is the layer MIR provides.

What MIR Is

Substrate, not authority. MIR is the recording layer. It does not make decisions, enforce execution, or grant permissions. It records events submitted by authenticated partners against authenticated entities, calculates the entity's tier at query time from accumulated history, and returns a deterministic recommendation that the consuming system applies its own policy to.

Deterministic, not AI. The tier calculation is a function of event count, history age, partner diversity, and recency weighting. No machine learning. No inference. No scoring of the entity. The same inputs always produce the same output, which makes the substrate externally auditable.

External to the consuming system. Events are submitted by authenticated partners, never by the entities they describe. The entity cannot self-modify its own MIR record. This separation is what makes the substrate evidence rather than self-report.

Neutral. MIR serves the entities it tracks, not just the organizations that submit events. Absence of history is not evidence of risk -- it is absence of signal. Presence of history is not evidence of safety -- it is a record of what the entity did, not a judgment about what the entity is. The consuming system decides what either one means in its own policy.

"Better decisions don't come from more data at runtime, but from knowing who you're dealing with before execution begins."

Two Deployment Modes

Cross-platform applies to humans, contractors, and service agents that operate across institutional boundaries. AI agents deployed within a single organization do not cross boundaries and use intra-org mode exclusively. Pricing is the same for both modes: $40,000 platform per year + $3 per entity per month. The mode determines how history is computed, not how it is billed.

The Architecture: Substrate, Not Authority

Every authorization system asks: "Is this entity allowed to do this?" MIR adds the question authorization stacks were never designed to answer: "Has this entity earned the right to do this right now?" The two questions live at different layers, with different responsibilities.

This separation is structural, not aesthetic. A substrate that makes decisions is no longer a substrate -- it is authority masquerading as evidence, and the regulator's "who decided" question collapses into "the system did." That is the automated-authority failure mode MIR's architecture is explicitly built against.

The Recommendations MIR Returns

At the moment of decision, the consuming system calls POST /v1/policy/evaluate with the actor, the action, and optional resource context. MIR returns one of four recommendations:

Each response includes claimStatus (clean / flagged / elevated), the entity's current tier, and a whyRec field that explains which inputs drove the recommendation. Debug mode (?debug=true) returns the full signal breakdown.

MIR returns a recommendation, not a decision. The consuming system decides what to do with it.

Integration Flow

1. Submit events. Partners send events via POST /v1/events using an API key. Each event carries the entity reference (SHA256-hashed external ID), action type, weight, and timestamp. No free-form metadata fields -- the input format is a blocklist, not a whitelist.
2. Tier accrues over time. Entity tier is calculated at query time from event count, history age, partner diversity (cross-platform), and recency weighting. Deterministic; no background job; recalculated on every query.
3. Evaluate at decision time. The consuming system calls POST /v1/policy/evaluate with the actor, action, and resource context. MIR returns the recommendation, tier, and claim status in milliseconds.
4. Consuming system decides. The consuming system applies its own policy -- regulatory holds, stake-based overrides, operational constraints -- to MIR's recommendation, then makes the decision and enforces it.
5. Report the decision back (optional but recommended). The consuming system reports its final decision via POST /v1/policy/decisions. This is what makes the audit trail complete and the conformance signal possible.

The Conformance Signal

The decision-report endpoint exists for a specific reason: it makes rubber-stamping observable. A consuming system that says "MIR is not authority -- we retain decision authority" but then wires ALLOW directly into execution with no policy applied is doing what the architecture is explicitly built against: laundering authority through integration.

MIR's conformance endpoint -- GET /v1/policy/decisions/conformance -- surfaces three signals to the partner's regulators or internal auditors:

• Agreement rate. Percentage of cases where the consuming system's reported decision matched MIR's recommendation. 100% across a high volume is the rubber-stamp signature.
• Override count. Number of cases where the consuming system documented a regulatory, stake-based, operational, or human-review override. Zero overrides under load is the same signature, viewed differently.
• Decision latency. Median time between MIR's recommendation and the consuming system's reported decision. Sub-50-millisecond median means there is no policy step in between.

What MIR Does NOT Do

The non-claims matter as much as the claims.

• MIR does not make decisions. The consuming system applies its own policy and decides. MIR's output is an input, not an output of authority.
• MIR is not AI. The policy engine is deterministic. No machine learning, no inference, no training. Tier calculations are arithmetic over event records.
• MIR does not enforce execution. Execution-control and evidentiary-closure layers compose alongside MIR, not below it. Each layer's authority belongs to its own owner.
• MIR does not operate inside the consuming system's trust boundary. Substrate is external by definition. The entity cannot self-modify its own record.
• MIR does not perform inference or scoring on entities. Tier is not a risk score. Claim status is not a verdict. The consuming system interprets the signals against its own policy.
• MIR does not assert identity integrity. The partner is responsible for verifying the entity is who it claims to be. MIR records what that identity did over time; it does not validate that the identity is real.
• MIR does not enable arbitrary lookups. Partners can only query entities they have authenticated. No browsing, no fishing, no third-party reads.

The Tier System

Tier is the substrate's quantitative summary of accumulated history. It is not a score. It is a band derived from event count, history age, and (for cross-platform) partner diversity.

• Tier 0. No history yet, or below provisional thresholds. The consuming system has no behavioral signal to evaluate against and decides accordingly.
• Tier 1. 10+ events, 14+ days of history, 1+ contributing partner (cross-platform). Provisional standing.
• Tier 2. 50+ events, 30+ days of history, 2+ contributing partners (cross-platform). Established standing.
• Tier 3. 200+ events, 90+ days of history, 3+ contributing partners (cross-platform). Trusted standing.

Intra-org tiers use the same event count and age thresholds but have no partner-diversity requirement. Recency weighting (shipped April 2026) reduces the impact of burst submissions on tier advancement, closing the basic farming attack class.

Dormancy decay applies to non-human entities only. AI agents and service accounts with no events for 90+ days drop one tier; 180+ days drops to tier 0. Computed at query time, resets immediately when new events arrive. Human entities do not decay -- a leave of absence should not reset earned standing.

Where MIR Lands First in the Enterprise

• 🤖 AI agent governance When an automated agent attempts a consequential action -- a database write at scale, an outbound payment, a privileged provisioning operation -- the consuming system queries MIR for the agent's accumulated history. Tier-3 standing for low-stakes operations is not the same as tier-3 standing for irreversible ones; the consuming system evaluates whether standing is proportional to the consequence.
• 💼 Contractor and vendor onboarding New contractors and vendors enter consequential workflows with no behavioral history at the consuming organization. Cross-platform MIR history -- if the entity has accumulated record at peer institutions -- provides the standing signal that exclusion screening and credentialing alone do not.
• 🔑 Service account oversight Long-lived service accounts often retain credentials and policy access far beyond the operational reality that justified them. MIR's accumulated record plus dormancy decay surfaces the gap between current authorization and current standing.
• 🏥 Claims-decisioning and prior-authorization automation In Medicare, payer operations, and healthcare claims, automated decisioning pipelines make thousands of determinations per day. MIR's recommendation provides the standing-with-history signal that audit defense (RAC, OIG, internal compliance) needs but post-decision logs cannot produce.
• 💳 Financial services -- AML, fraud, transaction monitoring At the moment a transaction flags, the investigator sees what the entity is allowed to do but not what they have actually done across institutions over time. MIR's cross-platform history reduces the gap between alert-stage signal and disposition-stage evidence.
• 🌍 EU AI Act and similar regulatory regimes Where regulation requires evidence that an AI system's consequential decisions were made on verifiable, contemporaneous record -- not reconstructed after the fact -- MIR's substrate plus conformance signal is the audit artifact regulators expect to see.

Compliance, Audit, and Procurement

MIR is built to be droppable into regulated-enterprise procurement. The audit artifacts are routine, not exception:

• Append-only audit log of every recommendation issued, with cryptographic integrity.
• Decision-report endpoint and conformance signal -- the consuming organization's regulators and auditors can verify the consuming system retained decision authority.
• SBOM (CycloneDX 1.5, JSON) published with each release.
• DPA available; sub-processors list current and disclosed.
• No PII. External IDs are SHA256-hashed; events carry no free-form fields by design.
• EU AI Act and GDPR alignment designed in from the start. Architecture is "evidence at decision time" specifically because that is what regulators are converging on requiring.

Specific questions: richard@mirregistry.com. Security-specific: security@mirregistry.com.

What MIR Cannot Do

An evaluator will find these eventually. They are stated here so that finding them is confirmation rather than discovery.

A compromised entity acting in pattern is invisible. An entity with a long, clean history whose credentials are taken over, and which then behaves exactly as it always has, produces exactly the signal it always produced. History narrows the question of whether an actor has standing. It does not close it, and this is a blind spot shared with every other trust mechanism rather than one the substrate solves.

Silence from the entity and silence from the partner are indistinguishable. The registry sees only what partners submit. When an entity's history stops accumulating, there is no way from inside the record to tell whether the entity went quiet or the reporting did. This bears directly on dormancy decay for non-human entities: the elapsed time being measured is time since the last reported event, which is not the same quantity as time since the last event.

Events are claims, not observations. MIR has no sensors, no agents in a partner's network, and no access to partner systems. Every event is an authenticated partner asserting that something happened. What the substrate offers is a durable, tamper-evident account of what was reported, by whom, and over what period, which is a narrower thing than truth about the world. The partner remains responsible for the integrity of what it submits, as it does for the integrity of the identities it submits against.

The boundary of the record can be declared. Absence of history has been ambiguous for that reason, so a partner declares its coverage during onboarding: which event types and source systems it undertakes to report, and which it expressly does not. Declarations are effective-dated and append-only, so an evaluation concerning a past date resolves against the declaration in force on that date. Every policy response carries the coverage in force, including when none is declared.

This does not make the record complete. Coverage does not affect tier, and the registry does not verify that a partner honors what it declared. The declaration is itself a claim, held on the record alongside the events, so an auditor can compare the two and find a partner reporting less than it undertook to report. Absence inside a declared scope is a fact about the entity, while absence outside one is a fact about the reporting, and an evaluator can tell which of the two they are looking at.

Pricing

All prospects route through /enterprise/apply; no self-service tier exists. The application gives MIR's team enough context to scope the integration and to confirm the consuming organization can retain decision authority over MIR's recommendations.