FAQ & Navigation

What is IDNA? A causal framework tracing trust: Identity → Data → Networks → AI.

Read Time: 2.5 min.

Target: Cloud security architects (DevSecOps).

Jump To Section

Licensing Inquiry
Identity - Data - Networks - AI

IDNA

To trust an interaction, you must govern Who, What, Where, and Why.

The Discovery

For decades, the industry has sold Identity (SSO), Data (DLP), Networks (Firewalls), and AI (Guardrails) as separate categories owned by different teams. We kept seeing systems fail because these siloes never communicated at runtime. A secure network call means nothing if the AI proposing the action has no attested identity or payload integrity.

We discovered that digital execution has a strict causal order. Identity must exist before data can attach; data must exist before it can move over a network; and networks must exist before AI decision logic can propose an action. AI is the youngest child in this chain, inheriting every unresolved security failure below it.

By mapping this causal lineage, we created IDNA. It is not a suite of products, but the minimum set of dimensions required for trust.

The Inversion

Metric Traditional Silos IDNA Framework
Integration Fragmented tools, reactive logs Unified runtime context (G-Tx)
Causal Awareness Ignored; tools operate in isolation AI inherits Identity/Data/Network trust
Verification Post-hoc audit trailing Cryptographic attestation at boundary

The Causal Chain

IDENTITY
Who
→
DATA
What
→
NETWORKS
Where
→
AI
Why

The New Capability

Because of this, you can now trace and govern the precise origin of any transaction across identities, payload contents, routing channels, and decision logic—eliminating the space where exploits hide.

Technical Specification

IDNA ≡ Causal Chain ≡ Trust Dimensions

Critical Aspects

Dimension Description Verification Method
Identity (Who) Attesting the actor's verified signature and authorization boundaries. Cryptographic key verification.
Data (What) Ensuring content integrity and payload boundaries during transition. SHA-256 payload integrity matching.
Networks (Where) Bounding routing and transport paths to secure, authenticated channels. TLS channel attestation.
AI (Why) Evaluating the decision rationale or model origin proposing the effect. Model provenance checks.

Validation Metrics

  • Attestation Certainty: 100% Attested
  • Causal Trace Overhead: < 5ms / layer
  • Integrity Match Rate: 100% matching

Example Applications

  • AI Inference: Bounding the input data schema and target endpoint for the inference payload.
  • Enclave Boundary: Verifying hardware-attested caller keys before revealing data blocks.
  • Supply-Chain: Sealing code artifacts into verifiable pipelines with identity locks.

Reference Implementation

// IDNA Attestation Validation
function validateIDNAContext(attestationBundle) {
  const { identity, data, network, ai } = attestationBundle;

  // Validate Identity
  if (!verifySignature(identity.pubKey, identity.signature)) return false;

  // Validate Data integrity
  if (computeHash(data.payload) !== data.expectedHash) return false;

  // Validate Network channel
  if (!network.isTLSAttested) return false;

  // Validate AI model provenance
  if (!verifyModelOrigin(ai.modelHash)) return false;

  return true;
}

Measurement Protocol

  1. Intercept incoming transaction at boundary.
  2. Extract attestation attributes for Identity, Data, Network, and AI.
  3. Verify identity signatures and hardware attestation keys.
  4. Verify payload SHA-256 hashes against original definitions.
  5. Assert network channel parameters match boundary requirements.
  6. Verify AI model provenance hash is in the allowed register.

IDNA Outcomes

Outcome-Oriented ≡ Testable ≡ Conformance Criteria

1. Identity Outcomes
  • •ID-OUT-01: Actions are attributable to an authenticated and authorized principal (human or non-human).
  • •ID-OUT-02: Context constraints (role, jurisdiction, scope) are evaluated prior to autonomous execution.
  • •ID-OUT-03: Identity binding influences admissibility, not only access.
2. Data Outcomes
  • •DA-OUT-01: Data inputs influencing execution are verified for integrity, provenance, and scope.
  • •DA-OUT-02: Constraints (thresholds/ceilings/refusal rules) are encoded as enforceable data and applied deterministically.
3. Networks Outcomes
  • •NW-OUT-01: Runtime integrity signals are monitored continuously independent of semantic reasoning.
  • •NW-OUT-02: Unsafe conditions trigger suppression/lockdown/refusal pathways before model output becomes admissible.
4. AI Outcomes
  • •AI-OUT-01: Model outputs are treated as hypotheses until admitted by an enforcement authority (Observer).
  • •AI-OUT-02: The system can refuse, qualify, or constrain outputs when invariants or conditions are violated.
  • •AI-OUT-03: All admissions/refusals are recorded with sufficient causal evidence for replay and examination.

Composition

As a Standalone Primitive: IDNA provides a structured schema for verify-on-receive APIs, validating incoming payloads across four variables.

As a Composed Architecture: IDNA feeds its structural context directly into the Cyber-Safety execution boundary, matches its attestation criteria against NovaProof surfaces, and is carried within the .NVX artifact.

Proof Surface

Verify the IDNA specification and attestation schemas.

GitHub Repository IDNA Specification