Skip to main content

Runtime Trust

GrayMatter runtime trust turns AI and workflow behavior into verifiable, RBAC-scoped evidence. The goal is to prove what code, policy, identity, data, and key versions were used for a runtime action without exposing private payloads.

Questions It Answers​

The trust layer should be able to answer:

  • Who owned the object involved in a runtime decision?
  • Which RBAC or ACL policy authorized the action?
  • Which generated API schema governed the action?
  • Which runtime, model, code version, and policy manifest were used?
  • Which key provider and key version protected sensitive fields?
  • Can a verifier confirm the result without plaintext access?

Architecture Principles​

  • api.hbs.yaml is the source of truth for trust objects.
  • Generated ThorAPI services own persistence.
  • RBAC and ACL are mandatory for every trust object.
  • Proofs contain hashes, signatures, identifiers, and redacted metadata, never secrets.
  • Key rotation is modeled explicitly with versions, activation windows, retirement, and rewrap jobs.
  • External verifiers consume REST resources or exported proof bundles, not database credentials.

Key Custody​

Database storage is allowed for wrapped and public material:

  • key metadata
  • wrapped data-encryption keys
  • public verification keys
  • key hashes and fingerprints
  • rotation events and access audit records

Database storage is prohibited for:

  • raw key-encryption keys
  • raw data-encryption keys
  • provider root tokens
  • KMS credentials
  • unwrapped private signing keys
  • plaintext secrets in logs or proof bundles

Relationship to SecureField​

SecureField remains the encryption enforcement point. GrayMatter runtime trust extends it with generated key objects, provider-aware rotation, and proof evidence around runtime actions.

Related: