A revision is a point-in-time reference used to evaluate authorization data at a specific state. In systems like SpiceDB, every permission check can be tied to a revision so the result reflects a known snapshot of relationship data. Datastores must verify that the requested revision is still within the window they can safely serve.
Expanded Definition
A revision is a point in time used to evaluate authorization data against a known snapshot of relationship state. In Zanzibar-style authorization systems, and in implementations such as SpiceDB, the revision lets a permission check answer a question against data as it existed at that moment rather than against a moving target. That matters because authorization is only reliable when the datastore can guarantee the requested snapshot is still within the period it can safely serve.
This is different from a general version number or audit timestamp. A revision is operationally tied to read consistency for access decisions, not just change tracking. In NHI and IAM contexts, the term is most often used when systems need deterministic permission checks across distributed stores, replication lag, and rapidly changing relationships between NHIs, resources, and roles. Definitions vary across vendors, but the core idea is stable: the check must resolve against a valid, durable state. For broader control context, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the governance language around access control and system integrity that revision-based authorization is meant to support. The most common misapplication is treating a revision like a simple database record ID, which occurs when teams ignore consistency windows and assume every stored state is safe for authorization.
Examples and Use Cases
Implementing revisions rigorously often introduces a consistency-versus-latency tradeoff, requiring organisations to weigh fast permission answers against the cost of rejecting checks when the datastore cannot serve a safe snapshot.
- An AI agent checks whether it may invoke a tool at a revision that matches the current relationship graph, so the decision cannot drift mid-execution.
- A service account request is evaluated against a revision captured before a role change, preventing a race where access is granted based on partially replicated data.
- A CI/CD pipeline validates an NHI entitlement at a safe revision before deploying infrastructure that depends on that entitlement.
- A security team reviews authorization incidents by replaying a decision against the exact revision active when the access was allowed.
- Authorization services reject a stale revision when the datastore can no longer guarantee correctness, forcing the caller to retry on a newer snapshot.
For a broader NHI risk lens, the Ultimate Guide to NHIs highlights how fragile service-account governance can become when access control assumptions are weak.
Why It Matters in NHI Security
Revisions matter because non-human identities often operate at machine speed, across many services, and with little human oversight. If authorization cannot anchor decisions to a safe snapshot, NHIs can inherit access that should already have been removed, or lose access in the middle of legitimate workflows. That creates a governance gap between intended policy and actual enforcement. NHIMG reports that only 5.7% of organisations have full visibility into their service accounts, which makes precise, revision-based evaluation even more important when teams are trying to determine what access existed at a specific moment.
This concept becomes especially important in incident response, when investigators must reconstruct whether a token, API key, or service account was authorized at the time a decision was made. It also supports Zero Trust thinking by forcing each check to stand on a verifiable state rather than trust cached assumptions. In practice, revision handling intersects with rotation, offboarding, and graph freshness, because stale authorization data can silently preserve privileges long after they should have been revoked. The most common operational failure appears after an access review, when a team discovers that a privileged NHI kept acting on stale permissions and the revision boundary is the only reliable way to prove what happened.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 | Revision-safe checks depend on correct authorization state and stale-data handling. |
| NIST Zero Trust (SP 800-207) | PDP/PEP | Zero Trust requires decision points to evaluate access against current, verifiable context. |
| NIST CSF 2.0 | PR.AC-1 | Access control depends on validated identity and authorization state at decision time. |
Ensure NHI authorization queries use safe snapshots and fail closed when state freshness cannot be proven.
