Cryptographic preservation and runtime evaluation of original intent

Research Question

What representation of original intent, captured at the Getting Started phase, is simultaneously cryptographically verifiable and semantically stable enough to function as a meaningful evaluation baseline for the Policy Decision Point (PDP) across the full operational lifecycle of a governed asset, including legitimate scope evolution?

Findings

Executive Summary

• Among the reviewed alternatives, the best-fitting representation of original asset intent is a signed, digest-addressed dual artefact that pairs a human-readable intent statement with a machine-readable intent declaration whose canonical runtime identity is the hash of the declaration rather than the prose.
• The declaration can keep the original triple of authorised-capability-set, authorised-data-scope, and authorised-action-envelope as its runtime evaluation surface, but only if each component is encoded as bounded typed claims that a policy engine can compare against subject, resource, action, and environment attributes and that can express capability attenuation.
• Legitimate lifecycle evolution should not rewrite the original intent record, because semantic stability is preserved best by keeping the base declaration immutable and adding append-only signed amendments that reference prior digests and carry explicit delta claims.
• This structure gives the Policy Decision Point and Policy Information Point a shared evaluable baseline and gives Large Language Model agents a bounded format they can compare tool calls against without relying on free-form prose interpretation.

Key Findings

1. Medium: A dual artefact that combines Ricardian-style prose, verifiable-credential-style typed claims, and an in-toto-style digest-bound subject is the best-fitting composite pattern among the reviewed alternatives for preserving original intent as both auditable human meaning and immutable runtime identity across the lifecycle.
2. Medium: The original triple of authorised-capability-set, authorised-data-scope, and authorised-action-envelope can serve as a workable runtime evaluation surface only when each component is expressed as bounded typed claims covering verbs, resource types, caveats, data classes, sinks, purpose classes, sequences, and quantitative limits.
3. Medium: The human-readable statement should remain an audit and rationale layer rather than the canonical runtime baseline, because semantic stability fails when prose remains unchanged while effective authority expands or when prose wording changes while machine authority does not.
4. High: Legitimate lifecycle evolution should be encoded as an append-only amendment chain in which every amendment references the base declaration digest and prior amendment digest, because mutable overwrites destroy the provenance required for later policy verification and audit.
5. Medium: The Policy Decision Point only needs a Knowledge-level event tuple derived from raw tool-call data, and that tuple should normalize actor, tool class, verb, resource type, data class, source, sink, purpose, side effects, and phase into the same vocabulary used by the declaration.
6. Medium: Large Language Model agent evaluability depends on closed vocabularies, credential schemas, examples, and stable type URLs in the declaration, because free-text fields alone leave decisive semantics inside unconstrained strings that agents cannot compare reliably.
7. Medium: The same typed declaration is a plausible baseline for prior-based Policy Information Point anomaly detection if it includes sensitivity tiers, forbidden sinks, purpose classes, and quantitative ceilings, because those features expose the attributes a prior model would need to estimate whether the observed task framing is plausible for the registered asset.
8. Medium: A lifecycle change should be processed as an amendment when asset identity, trust boundary, and primary protected-data family remain stable, while a new registration is required when those foundations change enough that the prior baseline no longer describes the same governed asset.

Assumptions

• Assumption: runtime telemetry can be normalized into stable subject, object, action, and environment style attributes for every relevant tool call. Justification: ABAC assumes such attributes exist, but this item did not test a concrete telemetry collector.
• Assumption: a production implementation can combine a verifiable credential envelope with an in-toto digest subject without incompatible trust semantics. Justification: the standards are composable on paper, but this item did not build an interoperability profile.

Analysis

• A Ricardian-only artefact preserves prose plus identifier semantics but lacks the richer schema, status, and evidence structures that modern interoperable claim exchange expects, while a verifiable-credential-only envelope preserves typed claims but does not on its own make the declaration hash the first-class runtime equality token.
• In-toto and Supply-chain Levels for Software Artifacts (SLSA) add the missing immutable-subject and dependency-lineage discipline needed to prevent silent mutation of the authoritative runtime baseline.
• ABAC and XACML then anchor the runtime side of the design, because they show that policy evaluation ultimately compares bounded attributes rather than prose intentions.
• The central tradeoff is therefore explicit: richer prose improves human context, but only typed bounded claims preserve machine evaluability and reduce reward-hacking opportunities.

Risks, Gaps, and Uncertainties

• The Verifiable Credentials Data Model does not define a domain ontology for capability, data, or action classes, so a production system still needs a controlled vocabulary profile.
• ZCAP-LD is a community draft rather than a finalized broad standard, so its caveat and delegation model is a strong reference but not a settled interoperability baseline.
• The representation is rich enough for the PIP prior model in principle, but this item did not estimate how much historical telemetry is needed before those priors become dependable in practice.
• Regulatory alignment was inferred from architecture-control language rather than from sector-specific supervisory guidance written specifically for agentic systems.

Open Questions

• What controlled vocabulary for purpose classes, action patterns, and caveats will remain portable across tools and organizations without becoming so abstract that runtime evaluation loses precision?
• Should partial revocation of individual capabilities be modeled as a special amendment type, or should revocation always issue a whole new declaration to keep verification simpler?
• How should the PIP handle rare but legitimate emergency overrides without normalizing exceptional high-risk behavior into the asset's expected baseline?

sources

• [x] Organisational intent formal specification, completed item — - organisation-level analogue and machine-checkable derivation precedent
• [x] Intent-Driven Development (IDD), completed item — - intent as the primary specification primitive above tests and contracts
• [x] Ricardian Contract model, completed item — - prose plus machine-readable plus cryptographic binding pattern
• [x] Language designed for LLM agents to produce, completed item — - bounded output format constraints for agent evaluability
• [x] DIKW transformation functions, completed item — - Data to Knowledge transformation framing for runtime evaluation
• [x] Formal intent specification and reward hacking, completed item — - why incomplete specifications are gameable
• [x] Universal policy synchronisation and integrity, completed item — - digest-bound lifecycle identity and attestation pattern
• [x] Invariant-based anomaly detection in the Policy Information Point (PIP), completed item — - prior-based anomaly detection requirement that consumes the baseline
• [x] Ricardian Contracts, Ian Grigg — - original architecture for human-readable plus machine-processable document binding
• [x] Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53 Rev. 5 — - authoritative control catalog
• [x] NIST SP 800-53 Rev. 5 landing page — - official publication landing page for the control catalog
• [x] Guide to Attribute Based Access Control (ABAC), NIST SP 800-162 — - subject, object, action, and environment evaluation model
• [x] eXtensible Access Control Markup Language (XACML) 3.0 core specification — - authoritative definitions of PAP, PDP, Policy Enforcement Point (PEP), and PIP
• [x] Verifiable Credentials Data Model, W3C Recommendation — - signed claims, schemas, proofs, status, and credential graphs
• [x] Authorization Capabilities for Linked Data (ZCAP-LD) — - capability delegation, attenuation, and caveats as a modern object capability reference
• [x] Statement layer specification, in-toto attestation — - digest-bound immutable subject semantics
• [x] ResourceDescriptor field type specification, in-toto attestation — - immutable digest and annotation semantics
• [x] Supply-chain Levels for Software Artifacts (SLSA) provenance v1.0 — - externalParameters, resolvedDependencies, and subject binding for provenance-carrying records