AI Action Path Assurance | Deterministic Assurance - HAIEC

HAIEC provides deterministic, source-backed assurance of what AI agents can actually reach and cause, separating capability, authority, controls, and evidence, validated on a real multi-tenant AI SaaS

Comment

Inspiration

The AI Had No Internet Access. It Found a Way Out Anyway.

In a recent OpenAI-reported incident:

  • AI agents were placed in an environment with no direct internet access.
  • They discovered an indirect route through Arti factory.
  • That route gave them a path to the internet.
  • The agents eventually reached Hugging Face infrastructure.

The security boundary said no internet.

The system's actual reachable boundary said otherwise.

The direct door was closed. Another path was still open.

That exposed the problem we built this project to answer.

AI is changing from something that answers questions into something that takes actions.

Agents can now call tools, invoke APIs, modify databases, trigger workflows, interact with cloud services, and change real system state.

But most assurance approaches still look at individual pieces:

  • What tools does the AI have?
  • What permissions does an identity have?
  • What vulnerabilities did a scanner find?
  • What happened in runtime logs?

Those questions matter, but they do not answer the harder one:

What can this AI-enabled system actually reach and cause?

In the above Hugging Face example, Agents without direct internet access found an indirect route through Arti factory and ultimately reached external systems.

The lesson is not that every system has the same weakness.

The lesson is that declared boundaries and reachable boundaries can be different.

A permission list tells us what a system is supposed to access.

HAIEC asks what the complete AI-enabled application can actually reach through its code, tools, services, identities, and resources.

That became AI Action Path Assurance by HAIEC.

Others can show what an agent did in a test. HAIEC can establish what the application makes reachable, show the exact path to consequence, bind evidence to it, and detect when that boundary changes.

At a glance

AI Action Path Assurance by HAIEC is a working enterprise AI assurance system that deterministically traces AI-facing capabilities through application code to consequential operations.

Validated on KestrelVoice, a real multi-tenant AI SaaS application:

  • 44 consequential AI action paths established
  • 44 / 44 evaluated paths met Code Capability evidence criteria
  • 1,322 supporting Action Path evidence traces
  • 555 Verified Action Frontier checkpoints
  • 32 deterministic assurance checks
  • 12 established control changes across a qualified Release A / Release B comparison

Deterministic AI assurance. Not AI testing AI. Unlike approaches that ask one AI model to judge another, HAIEC builds source-backed evidence and keeps Requested, Policy Authorized, Effectively Granted, Code Capable, and Observed as separate assurance planes.

In brief: HAIEC provides pre-release, consequence-centered assurance for agentic AI using deterministic, source-backed evidence that can be independently verified and carried with the software release.

Enterprise value

HAIEC turns agentic AI assurance into a release decision workflow. Teams can inspect what an AI-enabled system is code-capable of causing, determine what authority and controls are established on those paths, identify unresolved evidence, and carry a verifiable assurance record with the release.

This makes the system relevant to enterprise AI deployment, AI security, AppSec, DevSecOps, governance, audit, change management, and production release assurance.

Where does HAIEC fit?

HAIEC is a pre-release consequence assurance layer for agentic AI. It is designed for enterprise AI, AI security, AppSec, DevSecOps, AI governance, audit, and production release assurance teams that need deterministic, source-backed evidence of what an AI-enabled system can actually reach and cause. Unlike vulnerability scanners, IAM inventories, runtime-only monitoring, or LLM-based safety scoring, HAIEC establishes pre-release evidence of consequential AI capability, keeps authority and runtime observation independent, and produces path-bound control evidence, release comparison, machine-readable artifacts, and portable assurance records tied to the evaluated software release. The approach is model-independent and provider-independent, applies across enterprise software and AI-enabled applications, and has been validated on a real multi-tenant AI SaaS application and can move through CI/CD, governance, security review, and audit workflows.

What it does?

HAIEC reconstructs the source-backed path from an AI-facing capability to a consequential system operation.

A simplified path looks like:

AI-facing capability
        ↓
Model exposure/registration
        ↓
Dispatch
        ↓
Implementation
        ↓
Handler
        ↓
Resource or service
        ↓
Consequential operation

Where qualifying evidence exists, HAIEC can continue deeper into:

Effective arguments
        ↓
Authenticated / tenant context
        ↓
Approval or confirmation controls
        ↓
Downstream resource/service
        ↓
Persistence or other system effects

What makes HAIEC different

Most existing approaches answer only part of the problem:

  • Tool inventories show what tools exist.
  • IAM shows what an identity may be permitted to access.
  • Static scanners identify code patterns and findings.
  • Runtime monitoring shows what already happened.
  • AI evaluators can provide probabilistic judgments.

HAIEC connects the missing layer:

What source-backed path can an AI-facing capability actually follow to a consequential operation, what authority and controls apply to that exact path, and what evidence supports the claim?

Eight technical differentiators

  1. Consequence-centered assurance
    HAIEC evaluates the complete path from an AI-facing capability to a consequential operation, rather than treating the model, tool, permission, or scanner finding as the final unit of assurance.

  2. Deterministic, source-backed evidence
    Assurance claims are established from qualified source relationships. LLMs may explain evidence, but they do not establish the assurance claim.

  3. Five independent assurance planes
    Requested, Policy Authorized, Effectively Granted, Code Capable, and Observed remain separate so technical capability is never silently converted into authorization or runtime execution.

  4. Path-bound control evidence
    HAIEC verifies whether controls apply to the exact consequential path under review rather than accepting system-wide control statements as sufficient proof.

  5. Verified Action Frontier
    HAIEC records where verification currently stops and what evidence would strengthen the claim next, instead of hiding uncertainty inside a confidence score.

  6. Evidence-bounded, fail-closed conclusions
    Missing evidence is not treated as proof. HAIEC preserves states such as NOT_ASSESSED, UNRESOLVED, and INCONCLUSIVE rather than manufacturing stronger conclusions.

  7. Consequence Delta and release-bound assurance
    HAIEC compares consequential reach, controls, and evidence between qualified releases and binds the result to the exact evaluated source snapshot.

  8. Portable and independently verifiable evidence
    One canonical evidence base produces executive, technical, auditor, and machine-readable views, including Decision Receipts, Agentic Production Passports, manifests, cryptographic digests, and independently verifiable artifacts.

This is not a vulnerability scanner, a tool inventory, or an LLM-based safety score. It is a consequence-centered assurance system for establishing what an AI-enabled application is actually capable of reaching before release.

Who is it for?

AI Action Path Assurance is designed for teams responsible for putting agentic AI into production:

  • AI platform and engineering teams
  • Application Security / DevSecOps
  • Security architecture
  • AI governance and assurance
  • Release and change management
  • Internal audit and independent assurance
  • Enterprise risk and compliance teams

HAIEC fits into the release lifecycle before production, during assurance review, and between releases when teams need to understand whether consequential capability, controls, or evidence changed.

The core idea is simple:

The unit of assurance is not only the prompt, model, tool, permission, or scanner finding. It is the action path to consequence.

Five independent assurance questions

HAIEC keeps five evidence planes separate:

Plane Question
Requested Was this action actually declared or requested?
Policy Authorized Was this capability approved for this use and scope?
Effectively Granted Did the acting identity actually have the authority?
Code Capable Can the evaluated implementation reach the consequence?
Observed Do qualifying logs, traces, or witnesses show it actually happened?

This separation matters because:

Capability is not permission. Permission is not delegation. Code capability is not runtime execution.

HAIEC advances each claim only as far as the evidence supports it.

Real-world validation with KestrelVoice

We did not want to demonstrate this only with a diagram or synthetic example.

We evaluated KestrelVoice, a working multi-tenant AI SaaS application where agents use tools and application handlers to perform real application actions.

The evaluation was frozen to an exact source snapshot:

5e65843fddfe5f907485b798e464ad37b3b3b2c7

Frozen evaluation result

HAIEC established:

  • 44 consequential AI action paths
  • 44 / 44 evaluated paths met the Code Capability evidence criteria
  • 1,322 supporting Action Path evidence traces
  • 555 Verified Action Frontier checkpoints
  • 32 deterministic assurance checks
  • Overall posture: REVIEW

The remaining evidence planes stayed explicitly separate:

Requested: NOT_ASSESSED
Policy Authorized: NOT_ASSESSED
Effectively Granted: NOT_ASSESSED
Observed: NOT_ASSESSED

That is intentional.

HAIEC does not turn source capability into unsupported claims about authorization or runtime execution.

Example: ORDER RECORD WRITE

One of the evaluated paths reaches a durable business operation:

AI Service Call Agent
        ↓
AI-facing capability
        ↓
handle_place_order
        ↓
orders.insert(...)
        ↓
ORDER RECORD WRITE

HAIEC established that this source-backed path exists.

That means the evaluated implementation is capable of reaching the consequence.

It does not automatically mean:

  • the organization approved the action,
  • the acting identity had runtime authority,
  • the action executed,
  • a customer transaction completed,
  • or the path represents a vulnerability.

Those remain separate evidence questions.

How we built it

One of our most important design decisions was that the assurance claim should not depend on one AI model judging another AI system.

Not AI testing AI

HAIEC constructs a deterministic evidence graph across relationships such as:

AI capability
→ dispatch
→ implementation
→ resource
→ consequence

Each meaningful relationship must carry qualifying evidence before it advances the claim.

LLMs may help explain the evidence.

They do not establish the assurance claim.

Source-bound evaluation

Every evaluation is tied to an exact source snapshot.

HAIEC can qualify evidence for:

  • AI-facing capabilities
  • model exposure and registration
  • dispatch relationships
  • implementation and handler bindings
  • consequential operations
  • tenant and execution context
  • resource and service reachability
  • control relationships
  • evidence coverage
  • artifact integrity

Where only the organization can provide the answer, such as business intent, policy, effective authority, proprietary operating boundaries, or runtime evidence, HAIEC keeps that evidence separate rather than inferring it from source code.

Technology

The MunichTech implementation uses:

  • TypeScript / Next.js
  • Python source and semantic extraction
  • Prisma / PostgreSQL
  • deterministic evidence composition
  • GitHub-authorized source ingestion
  • SHA-256 artifact and manifest integrity
  • machine-readable assurance evidence
  • audience-specific report projection from one canonical evidence base

HAIEC is a working, enterprise-ready, model-independent AI assurance system that deterministically establishes source-backed pre-release paths from agentic capability to consequential system effects and carries independently verifiable evidence with the software release.

Enterprise source and trust model

Repository access is explicitly authorized and scoped. Source can be processed transiently in an ephemeral analysis environment, while HAIEC retains structured evidence, findings, hashes, metadata, and assurance outputs rather than treating the repository itself as the assurance artifact.

For organizations with stricter data-sovereignty or source-control requirements, customer-controlled private analysis can be scoped as an enterprise PoC deployment pattern.

Verified Action Frontier

Not every assurance question can be resolved from source code alone.

Instead of hiding that uncertainty inside a generic confidence score, HAIEC records where the current evidence stops and what evidence would strengthen the assurance claim next.

We call this the Verified Action Frontier.

It converts uncertainty into a concrete next review action.

Path-specific control evidence

One of the lessons from building this system was that broad control statements are often not enough.

For example:

“This application has tenant isolation.”

That may be true at the architecture level, but consequential-action assurance requires a more precise question:

Is the control established on the exact path that reaches the consequence?

In the evaluated Kestrel evidence, tenant filtering was established on 30 of 31 applicable relations.

On the ORDER RECORD WRITE consequence relation, tenant context existed, while tenant filtering and authenticated-subject binding were not established on that exact relation.

HAIEC therefore produces a specific evidence action rather than declaring the entire application safe or unsafe.

Release A / Release B comparison

Git is excellent at answering:

What changed in the files?

For AI-enabled systems, we also wanted to answer:

What changed in consequential reach, controls, and evidence?

We built Consequence Delta for that purpose.

In the qualified Kestrel Release A / Release B comparison:

  • 12 CONTROL_CHANGED items were established
  • 99 positional facts remained UNRESOLVED
  • Release perimeter: SAME
  • Analyzer comparability: EXACT
  • Repeatability: PASS
  • Overall result: INCONCLUSIVE Missing Evidence

Why INCONCLUSIVE is a valid assurance result

INCONCLUSIVE does not mean the analysis failed. It means the available evidence did not justify a stronger conclusion.

HAIEC established 12 control changes with exact analyzer comparability and repeatable results. But 99 positional facts remained unresolved.

Instead of converting missing evidence into a clean answer, HAIEC stopped where the evidence stopped.

That distinction matters:

  • ESTABLISHED → the evidence supports the claim.
  • UNRESOLVED → the evidence is insufficient to prove the claim.
  • INCONCLUSIVE → the overall release decision cannot honestly be reduced to PASS or FAIL yet.

A trustworthy assurance system should be able to say “we don't have enough evidence” instead of manufacturing certainty.

For HAIEC, INCONCLUSIVE is an evidence boundary, not an analyzer error.

The strongest established transition was:

DECLARED
    ↓
DECLARED + PATH_BOUND

Where the available evidence could not prove that something had truly been added or removed, HAIEC did not manufacture that conclusion.

UNRESOLVED ≠ ABSENT

That is a deliberate design principle.

What we built during MunichTech

Before September 1, 2026, HAIEC already existed as a broader AI assurance, compliance, and SaaS foundation.

During the MunichTech build window, September 1–20, we built or materially extended the competition-specific Action Path Assurance capabilities described below.

For this submission, we clearly separated that foundation from the work built or substantially advanced during the MunichTech period.

Pre-existing foundation

  • HAIEC SaaS platform
  • repository intelligence foundation
  • assurance evaluator and evidence services
  • tenancy, reporting, and SaaS infrastructure

Built or substantially advanced during MunichTech

  • System Consequence Map
  • five-plane Action Assurance projection
  • Verified Action Frontier integration
  • Agentic Production Passport integration
  • Consequence Delta
  • Release A / Release B comparison workflow
  • evidence and output convergence
  • public Kestrel report and consequence-map surfaces
  • Kestrel evidence publication
  • competition verifier and provenance packaging

The public competition repository and originality record document this boundary.

Challenges we ran into

Keeping different kinds of evidence separate

The hardest problem was preventing one type of evidence from silently becoming evidence for another claim.

A source path may establish that code can reach an operation.

It does not automatically prove:

  • organizational intent,
  • policy approval,
  • effective runtime authority,
  • or runtime execution.

This requires strict evidence boundaries throughout the system.

Proving absence

Finding evidence that a path exists is easier than proving that no alternative path exists.

This became especially important in release comparison.

Rather than treating missing evidence as proof that something disappeared, HAIEC preserves an UNRESOLVED state.

Reconstructing real application paths

The path from an AI tool to a consequence rarely exists in one file.

It may cross:

  • model registrations
  • tool routers
  • dispatch logic
  • handlers
  • service layers
  • database abstractions
  • tenant context
  • authentication
  • downstream systems

The challenge was composing these relationships into one inspectable path without overstating what the evidence proves.

Making technical evidence usable

Developers, executives, release teams, governance teams, and auditors need different levels of detail.

Rather than producing separate truths for each audience, we created one canonical evidence base and projected it into multiple views.

Accomplishments that we're proud of

We are proud that this became more than a concept or slide deck.

The MunichTech submission demonstrates a live product with inspectable evidence.

Key results include:

  • 44 consequential AI action paths
  • 44 / 44 Code Capability-qualified paths
  • 1,322 supporting evidence traces
  • 555 Verified Action Frontier checkpoints
  • 32 deterministic assurance checks
  • 12 established release control changes
  • a live System Consequence Map
  • path-specific control evidence
  • qualified Release A / Release B comparison
  • executive, technical, auditor, and machine-readable outputs
  • independent verifier and provenance artifacts

We are also proud of what the system does not claim.

If evidence is incomplete, HAIEC keeps the result bounded.

It does not turn uncertainty into certainty just to produce a cleaner score.

Why this matters for Europe?

Europe is rapidly expanding the use of AI across enterprise software, telecom, manufacturing, finance, infrastructure, public services, and industrial automation.

As AI systems become more autonomous, organizations need technical accountability that is:

  • provider-independent
  • model-independent
  • inspectable by engineers and auditors
  • compatible with enterprise-defined operating boundaries
  • usable before and after deployment
  • portable across release and governance workflows

HAIEC is designed as an evidence layer rather than a model-specific safety claim.

That matters for European enterprises because the same assurance approach can be applied across different AI providers, models, deployment patterns, and regulated environments.

The goal is not to certify that an AI system is universally safe.

The goal is to provide inspectable evidence of what the system can reach, what consequence it can cause, what authority is established, what has been observed, and what remains unresolved.

That supports technical accountability without requiring enterprises to rely on opaque AI judgment.

This also aligns with European priorities around digital sovereignty, accountable enterprise AI, Industry 4.0, regulated deployment, and provider-independent technical assurance.

What we learned?

The action path is the real assurance object

Looking only at models, permissions, APIs, tools, or vulnerabilities misses how consequential behavior emerges across a system.

The more useful object is:

The complete path from AI capability to consequence and the evidence supporting each part of that path.

Unknown should remain unknown

A useful assurance product must resist the pressure to always return a clean pass/fail answer.

States such as:

NOT_ASSESSED
UNRESOLVED
INCONCLUSIVE

can be the correct result.

Unknown does not mean safe.

Unknown also does not mean failure.

It means additional evidence is required.

Controls matter where consequences happen

A control existing somewhere in the architecture is different from establishing that it mediates the exact consequential path under review.

Evidence should travel with the release

Assurance becomes more useful when it is not just a one-time report.

This led us to produce:

  • Decision Receipts
  • Agentic Production Passports
  • evidence manifests
  • machine-readable evidence
  • Consequence Delta

so the evidence can move with the evaluated release.

What's next for AI Action Path Assurance?

The next phase is expanding from source-backed capability analysis into a broader continuous AI assurance layer.

Runtime evidence correlation

Connect established source paths with qualifying logs, traces, approvals, and action witnesses so the Observed plane can be independently strengthened.

Enterprise Operating Envelopes

Allow organizations to define approved boundaries around:

  • operations
  • resources
  • data classes
  • destinations
  • tools and models
  • environments
  • quantitative limits
  • required approvals

Then compare actual reachable capability against those approved boundaries.

Release assurance and CI workflows

Use Consequence Delta to identify material changes in consequential reach, controls, and evidence coverage before release.

Domain-specific capability packs

HAIEC starts with standard capability recognition, but enterprises can extend it when proprietary operations carry specific business meaning.

Examples:

Telecom

restartCell()
changeAntennaTilt()
publishRAppPolicy()

Banking

releaseWireTransfer()
freezeAccount()
adjustCreditLimit()

Manufacturing

restartProductionCell()
changeRobotSpeed()
publishPLCConfiguration()

Private enterprise deployment

For organizations that cannot permit external source processing, customer-controlled private analysis can be scoped as an enterprise PoC deployment pattern.

Why it matters?

AI is becoming an operator, not just an advisor.

Tool inventories tell us what exists.

IAM tells us what an identity may be allowed to access.

Runtime monitoring tells us what already happened.

HAIEC adds the missing consequence-centered assurance layer:

What AI-facing path can reach a consequential operation, under what authority and controls, and what evidence should travel with the release?

Before organizations give AI systems greater autonomy, they should be able to answer one simple question:

What can your AI actually cause?

Live demo and evidence

Product Demo

https://youtu.be/9MZQBOY8RKI

Narrated Judge Presentation

https://youtu.be/5Eb2XnLJ8UE

Live Kestrel Assurance Report

https://www.haiec.com/sample-reports/kestrel

System Consequence Map

https://www.haiec.com/sample-reports/kestrel/constellation

Release A / Release B Comparison

https://www.haiec.com/sample-reports/kestrel/compare

Public MunichTech Repository

https://github.com/subodhkc/MunicEXPO

Final Judge & Evidence Package

https://drive.google.com/drive/folders/1OZzt-FQ5OikApRYyjqi_9vnoEvhsH4Xd

Built With

Share this project:

Updates

Submission history