Tuesday morning. A new contractor gets provisioned. Valid credentials, valid permissions, authorized role. By Wednesday, a $200K wire transfer goes through. Three weeks later, forensics discovers the account was compromised at onboarding.
The credentials were real. The person behind them wasn't.
This is not a hypothetical. This pattern repeats across every industry that issues credentials to new entities -- employees, contractors, vendors, AI agents, service accounts. The system verifies identity. The system checks permissions. Both pass. The action executes. And nobody asks the one question that would have changed the outcome:
Has this entity earned the right to do this?
Two timelines
Same contractor. Same credentials. Same Tuesday morning. The only difference is whether the system has access to behavioral history at the point of decision.
Without Participation History
Credentials and policy only
With Participation History
Credentials + policy + behavioral track record
The gap is not identity. The gap is history.
Both systems verified identity. Both checked permissions. Both passed. The difference was a single input: behavioral track record at the point of decision.
The first system asked: Is this entity authorized? The answer was yes.
The second system asked: Has this entity earned the right to take this action? The answer was no. Tier 0. Zero history. One day old. And the action was a $200K wire transfer.
That question -- has this entity earned the right? -- is the question most authorization systems cannot answer. Not because they lack technology, but because they lack the input. They have identity. They have policy. They don't have participation history.
What changes with participation history
An entity that has been operating in your environment for 90 days with 200+ verified actions has a fundamentally different risk profile than one provisioned yesterday. Both have valid credentials. Both satisfy role-based policies. But they are not the same risk.
With participation history as an input, the policy engine can make that distinction at the point of decision:
- Tier 0 -- no history. High-stakes actions require step-up or deny.
- Tier 1 -- 10+ events over 14+ days. Entity is distinguishable from brand new.
- Tier 2 -- 50+ events over 30+ days. Standard actions proceed with less friction.
- Tier 3 -- 200+ events over 90+ days. Maximum earned trust from behavioral evidence.
The policy engine returns ALLOW, STEP_UP, LIMIT, or DENY based on the entity's accumulated history -- not just their credentials and role.
This is not a score. MIR does not rank, rate, or judge entities. It records what they have done and surfaces that history as a signal at the point of decision. The consuming system decides what to do with it. MIR provides the evidence. Your system provides the judgment.
Who this applies to
This is not just a contractor problem. Every entity in your environment has this gap:
- New employees with valid credentials requesting elevated access on day one
- AI agents spawned five minutes ago with the same permissions as one operating for 90 days
- Service accounts provisioned for a project and never decommissioned
- Vendors accessing your systems with credentials you issued but no operational track record
Every one of them passes the credential check. Every one of them satisfies the policy check. The only thing that distinguishes them is what they've actually done.
The question your system should ask
Every authorization system asks: Is this entity allowed to do this?
The question that's missing: Has this entity earned the right to do this right now?
That's the question that turns a $200K loss into a 16-minute detection. Not better credentials. Not more policy. Just one additional input -- behavioral track record -- at the point of decision.