Frequently Asked Questions

What problem does MIR solve for an enterprise?

Your authorization stack tells you who is asking and what they are allowed to do. Neither tells you what that entity has actually done with similar permissions in the past.

For employees, contractors, AI agents, and service accounts operating at scale, the question that matters at decision time is: has this entity earned the right to do this right now?

MIR records what entities have done and surfaces that history as a recommendation at the moment of decision. Identity says who. Policy says what. MIR says what they have actually done.

What does MIR actually do?

For any action attempt, MIR returns one of four recommendations:

• ALLOW -- accumulated evidence is sufficient at this tier with no claim concerns
• STEP_UP -- allowable in principle, but additional verification proportional to the action's stakes is warranted
• LIMIT -- allowable in a constrained form (reduced scope, capped amount, restricted destinations)
• DENY -- the signal pattern is insufficient or actively concerning for an action of this class

Each response includes the audit ID, the tier resolved, claim status, and a deterministic explanation string (whyRec). Your authorization, governance, and compliance systems consume these recommendations to make their own decisions.

What MIR is not

These commitments are architectural, not marketing:

• Not an authorization layer. MIR recommends. Your systems decide and enforce.
• Not AI. Tier thresholds are deterministic functions of event count, history age, and recency. No models, no scores, no inference.
• Not an identity provider. Your org is responsible for establishing that an entity is who it claims to be. MIR records what that identity has done over time.
• Not a predictor. MIR records what entities have done, not what they will do.
• No PII. External IDs are SHA256 hashed. Events carry no free-form metadata by design.

How is MIR different from an authorization layer?

Authorization (OPA, Cerbos, Oso, custom RBAC) answers "is this entity allowed to do this?" -- a static check against a permission set. MIR answers "has this entity earned the right to do this right now?" -- a query against accumulated behavioral history. Both layers are required. Authorization without behavioral history evaluates against snapshot context; behavioral history without authorization has no enforcement layer to consume it.

Is MIR an AI product?

No. The policy engine is deterministic. Tier thresholds are exact functions of event count, history age, and recency weighting. No models, no inference, no training, no scores. Two queries against the same recorded events return the same result. This is intentional -- it is what makes the substrate auditable and re-derivable post-incident.

How is MIR different from anomaly detection or ML risk scoring?

Anomaly detection and ML risk scoring infer that something is wrong. MIR records what has actually happened. The two layers solve different problems. Anomaly detection tells you "this looks suspicious." MIR tells you "this entity has accumulated this much evidence at this tier with this claim status." Your consuming system can use both signals; they do not compete.

Does MIR make decisions for my org?

No. MIR returns recommendations. Your consuming system writes its own policy artifact that maps recommendations to operational responses (e.g., what STEP_UP means for a high-stakes finance action vs. a routine read). The architectural separation is intentional -- MIR provides queryable evidence; your org retains the decision; the audit trail captures both layers separately so a third party can re-derive whether your decision followed reasonably from MIR's recommendation, and whether MIR's recommendation followed deterministically from the underlying signal data.

How does enterprise participation differ from marketplace?

For marketplace partners (.org), participation is voluntary and user-initiated. Users link their accounts across platforms because portable history serves them.

For enterprise partners (.com), participation is org-managed and mandatory by default. Your org submits events for entities operating in your environment as part of its infrastructure. Entities (employees, contractors, AI agents, service accounts) do not opt in or out -- the org records what they do because the org owns the operating environment in which they act.

Do entities opt in or are they tracked by default?

Tracked by default in enterprise mode. The org submits events for entities under its identifiers; the entities do not have an opt-out at the substrate level. This is structurally analogous to how an employer records timekeeping, badge access, or corporate device usage today -- the org owns the operating environment, the substrate records what happens within it.

What about religious organizations and charities?

Religious organizations and charities use a hybrid mode (participationOptional flag). Human members can opt out of participation; the substrate respects the flag and skips events for opted-out humans. AI agents and service accounts in those orgs are still tracked because they have no consent capacity -- the named human authorizer is responsible for them.

Who can opt out?

In enterprise mode, no one by default. The participationOptional flag is set at the partner level for religious orgs and charities specifically. In all other enterprise contexts, the org's commitment to its own governance includes recording entity behavior.

Who decides which entities are linked?

In enterprise mode, the org decides. Linking is org-managed: your org submits events for entities under its identifiers, and the substrate records them. There is no user-side linking flow because there is no user choice in the loop -- the org owns the operating environment.

Can AI agents link across organizations?

No. AI agents are intra-org only. They operate inside your environment, under your authority chain, with their behavior recorded against your tier mechanics (no partner diversity required).

Cross-platform mode applies to humans, contractors, and service agents that operate across institutional boundaries. AI agents that cross those boundaries become a different category of risk, and the substrate refuses to model them as cross-platform entities.

What is a service agent?

A service agent is a vendor-provided AI or service account that operates inside your environment but originated from a third-party vendor -- distinct from an AI agent (which is internal to your org). Service agents may be cross-platform if they operate across multiple consuming systems.

How does MIR support AI agent governance?

Every AI agent created in your environment has a named human authorizer at the root of its spawn lineage. The substrate records the lineage, the kickoff event, and every action the agent takes. STEP_UP, LIMIT, and DENY recommendations against the agent surface to the human authorizer at the root of the lineage tree.

This converts "human in the loop" from a constant pre-condition for every agent action (which would make agents operationally useless) into a conditional pre-condition triggered by substrate signals. The substrate is the gate that decides when human attention is required.

How does STEP_UP work for an agent?

The agent cannot supply additional verification of its own behavioral evidence -- that would be self-verification, which the substrate refuses by design. STEP_UP for an agent escalates to the named human authorizer at the root of the agent's spawn lineage:

• Synchronous flows: the human authorizer reviews the proposed action with the substrate's signal breakdown and approves or denies.
• Asynchronous flows: the agent's request is queued; the human is notified; the action executes only when the human approves, or expires after a configured timeout.

How does DENY surface for an agent?

DENY for an agent additionally notifies the named human authorizer asynchronously. This is not a request to override -- the substrate's recommendation stands. It is a notification that a system the human is responsible for has been refused. Common consuming-system policy: repeated DENY recommendations for the same agent trigger automatic permission downgrade or temporary suspension.

What if the human authorizer is unavailable?

The consuming system needs a documented escalation chain (delegate authorizer, on-call backup, fallback to default-deny). For agents in fully autonomous deployment contexts where no human authorizer is reachable, STEP_UP defaults to DENY -- if the human cannot be reached, the action does not proceed.

What are ALLOW, STEP_UP, LIMIT, and DENY?

These are MIR's four recommendations. ALLOW = accumulated evidence is sufficient. STEP_UP = additional verification is warranted. LIMIT = action allowed in constrained form. DENY = action should not proceed. Each is paired with a signal breakdown (tier, event count, history age, claim status, audit ID) and a deterministic whyRec explanation. Your consuming system maps recommendations to operational responses based on action class and stakes. See the enterprise API reference for details.

How does MIR calculate tiers?

Cross-platform tiers also require partner diversity (1+ for tier 1, 2+ for tier 2, 3+ for tier 3). Intra-org tiers (used by enterprise partners by default) skip the diversity requirement.

What is recency weighting?

Events count at half weight for the first 7 days after MIR receives them, full weight thereafter. This closes the burst-submission attack class -- you cannot game an entity's tier upward by dumping a large batch of events the night before a high-stakes action.

What is dormancy decay and which entities does it apply to?

Non-human entities (AI agents, service accounts) experience tier dormancy decay:

• Under 90 days since last event: no decay
• 90-179 days dormant: drop one tier
• 180+ days dormant: drop to tier 0

Humans do not decay. A 3-month leave of absence should not reset earned trust. Decay is computed at query time (not stored) and resets immediately when new events arrive.

What is whyRec?

whyRec is a deterministic, human-readable explanation string returned with every recommendation. It describes the rule that fired with the actual signal values, not interpretation of the entity. Suitable for display in human-review surfaces (agent escalation UIs, audit logs) and for inclusion in downstream closure artifacts.

Example: "Action 'finance.transfer' requires tier 3; actor at effective tier 2 (raw tier 2, recency penalty: 4 events under 7 days at half weight); step-up required: mfa, manager_approval; claim status clean."

The string is deterministic -- same input produces the same output. It is not LLM-generated.

What is a claim?

A claim is a recorded attribution-layer event: chargeback, fraud report, policy violation, abuse, suspension, identity dispute. Claims are recorded but not judged. The substrate records the claim and surfaces it; your consuming system decides what it means.

How do claims affect tier?

Claims do not affect tier directly. Tier is a function of recorded behavior + age + recency. Claims surface separately in claimStatus, so your consuming system can apply its own policy to claim-flagged entities.

What is claimStatus?

Every policy response includes claimStatus with one of three values:

• clean -- no active claims
• flagged -- 1-2 active claims
• contested -- 3+ active claims

Your consuming system's policy decides what each level means in context (e.g., a single chargeback might reduce credit limits without blocking transactions; three active claims might trigger account review).

What data does MIR store?

For each event: the partner that submitted it, the SHA256-hashed external ID of the entity, the event type, the timestamp, an outcome (success / failure / partial), and minimal structured metadata (no free-form text, no PII).

For each policy evaluation: the audit ID, the actor type, the action, the resource type if any, the recommendation, the tier resolved, the signal breakdown, and the timestamp.

Is any PII stored?

No. External IDs are SHA256 hashed before they reach the database. Events carry no free-form metadata. The substrate is structurally incapable of storing PII because the input schema rejects it.

How is the audit trail structured?

Every recommendation has an audit ID. Your consuming system logs its own decision with the same audit ID. Both records are independently reviewable. A third party can:

1. Re-derive MIR's recommendation from the recorded events and the policy version
2. Re-evaluate your consuming system's decision against your written policy
3. Verify that each layer behaved correctly

Can we re-derive a recommendation post-incident?

Yes. MIR's policy engine is deterministic. Given the recorded events, the action, and the policy version, the same recommendation is produced at audit time as at decision time. This is what makes the substrate suitable for post-incident review without depending on the originating system remaining available. Decision-time and audit-time return the same observation.

What are the enterprise pricing tiers?

Substrate procurement is a sales conversation. Custom enterprise pricing available for deployments above 10,000 entities.

How do we integrate?

The official SDK is TypeScript, distributed privately to partners. REST API documentation is on the enterprise API page. Standard integration:

1. Submit events for your entities via POST /v1/events
2. Query for policy recommendations via POST /v1/policy/evaluate at the moment of action
3. Log MIR's audit ID alongside your consuming system's decision

Most partners are integrated within a sprint.

How do we contact you?

Apply through the enterprise application or email hello@mirregistry.com.