Skip to main content
Enterprise Evidence-Bound Assurance

Can you prove what this AI can actually cause?

Start with one consequential AI system, one primary assurance question, and the minimum evidence needed to answer it. HAIEC maps supported action and access paths, correlates authority and control evidence where available, preserves what remains unknown, and delivers a technical and executive assurance baseline.

Typical scoped engagement: $25K–$75K. Initial evaluations are commonly 4–8 weeks after readiness. Final timing, evidence depth, testing authority and deliverables are defined in the SOW. Expansion is evidence-bound and not automatic.
Explicit scope Minimum sufficient access Missing evidence remains unknown Non-production first where practical
When to Scope an Enterprise POC

A serious-buyer motion for consequential AI decisions.

pre-pilot / pre-production approval
consequential agent rollout
new MCP/tool access
enterprise architecture/security review
procurement / third-party risk review
regulated or sensitive-data workflow
authority expansion
incident / near-miss follow-up
evidence gap before executive approval
The Enterprise Assurance Gap

Policy does not tell you what the implementation can actually do.

An AI application or agent may be intended for one task while its credentials, tools, APIs, code paths or infrastructure expose a broader action surface. Conventional code scanning, governance workflows and questionnaires each see part of the picture. HAIEC evaluates the supported evidence across those boundaries and makes the unresolved gaps explicit.

Evidence plane
Requested
What action or outcome was sought?
Evidence plane
Policy Authorized
What did policy allow?
Evidence plane
Effectively Granted
What access and credentials were actually available?
Evidence plane
Code Capable
What actions could the implementation reach?
Evidence plane
Observed
What does authorized runtime or action evidence show occurred?

Any plane can remain UNKNOWN when evidence is insufficient.

Start Small Enough to Prove Value

One system. One assurance question. One decision.

The POC is deliberately bounded. It is not an enterprise-wide promise of visibility or an open-ended security review. The scope is defined around a customer decision that existing evidence cannot answer confidently.

Can this support/refund agent reach financial mutation paths outside the intended workflow?
What services/resources become reachable through transitive tool/service chains?
Where can one agent influence another through shared resources, queues, memory or deferred mechanisms?
What is source-visible versus effectively granted versus observed?
Which credential/identity references are associated with consequential paths, and where does provider permission remain unknown?
Can the agent reach evaluator or grading infrastructure?
Where does evidence stop before the enterprise decision being made?

Examples illustrate the evaluation pattern. Actual support depends on the system, evidence sources and approved scope.

Evaluated Boundary

Define the evaluated boundary before analysis begins.

AI application or agent
Repository, module or service
Selected workflow or action family
MCP / tool ecosystem
Identity, credential and authority chain
APIs and external services
Data stores and queues
Provider / deployment configuration
Selected runtime or action evidence where authorized
High-consequence action surface

Source code is one evidence source. Depending on scope, HAIEC can also use deployment configuration, infrastructure artifacts, provider metadata, containers and runtime evidence.

Where required, the evaluation can run fully inside your environment — a local Docker deployment with telemetry disabled — so evidence stays inside your boundary for the duration of the POC.

POC Method

From scope to decision in a controlled evaluation.

1

Define

Set the business decision, system, consequence, primary assurance question and explicit exclusions.

2

Connect

Approve the minimum evidence and access required for the question. No broader authority is implied by possession of a repository, credential or environment.

3

Discover

Identify supported systems, agents, models, tools, dependencies and evidence sources within the evaluated boundary.

4

Map

Reconstruct supported relationships among identity, credentials, APIs, tools, data, infrastructure and consequential actions.

5

Validate

Run applicable source, control, isolation, behavioral or other authorized checks based on the selected evidence depth and testing authority.

6

Prove

Preserve findings, evidence provenance, limitations, unknowns and review outputs.

7

Review

Deliver a technical working session and executive decision readout.

Evidence Access Ladder

Use the minimum evidence depth needed for the decision.

L0

Document & Declaration

Documents and customer declarations. No implementation or runtime claim.

L1

Source & Implementation

Approved source and implementation artifacts. Supports implementation-visible findings only.

L2

Control & Authorization

Relevant IAM, permission and control evidence added for authority/capability correlation.

L3

Controlled Behavioral Verification

Authorized lab or sandbox behavior under named identities and explicitly permitted actions.

L4

Production-Relevant Evidence

Approved production-relevant evidence, read-only by default. No implied production actuation.

The selected level is part of the POC scope. More access is not automatically better; the objective is minimum sufficient evidence for the assurance question.

Outputs

Outputs built for a technical decision — and an executive one.

Potential contracted outputs, depending on scope:

AI System Baseline

A bounded record of the evaluated system, included components, versions/context and evidence sources.

System Constellation

An evidence-linked representation of supported relationships among agents, identity, credentials, tools, APIs, data, infrastructure and consequential actions.

Evidence Coverage / Frontier Map

What evidence was available, what it supports and where coverage remains insufficient.

Security / Control Findings

Material supported findings from applicable source, control, isolation or authorized behavioral analysis.

Authority & Capability Divergence

Where intended or policy-authorized behavior differs from effectively granted access or code-capable action.

Agent Reachability Summary

Reachability conclusions where qualified by source and evidence boundaries.

Shared-Substrate / Potential Influence Paths

Potential influence channels through scope-matched resources or deferred mechanisms, where qualified.

Evaluation-Integrity Exposure

Exposure to evaluator or grading infrastructure where qualified by source evidence.

Unknowns & Limitations Register

Unresolved evidence is recorded rather than converted into a clean result.

Decision Receipt

Structured evidence references and disposition context for selected assurance decisions where supported.

Prioritized Validation Backlog

What should be remediated, re-tested or investigated next.

Executive Decision Readout

A bounded decision readout with possible outcomes: Proceed to Pilot / Remediate & Retest / Evidence Upgrade / Stop or No Expansion.

Decision Outcomes

Proceed to PilotRemediate & RetestEvidence UpgradeStop or No Expansion

These are engagement outputs, not guarantees. The final recommendation depends on the evaluated evidence boundary.

Timeline

A defined evaluation window — after readiness.

A typical bounded POC targets approximately 4–8 weeks for the initial evaluation after the POC Readiness Date. The execution clock begins only after the agreed scope, evidence, access, security/privacy approvals and commercial prerequisites are ready. Phases below are typical and overlap depending on scope.

Pre-Day 1Readiness, scope and authorization freeze
Week 1Evidence intake and system baseline
Weeks 1–3Mapping and source analysis (typical, depending on scope)
Weeks 2–5Evidence correlation / approved validation (typical, depending on scope)
Weeks 3–7Context review, remediation/retest where included (typical, depending on scope)
Weeks 4–8Technical closeout and executive decision readout (typical, depending on scope)
Security & Operating Posture

Enterprise evaluation without unbounded access.

Minimum sufficient access
Explicit evaluated boundary
Non-production first where practical
Named identities and targets
Enumerated testing authority
Read-only production-relevant access by default
No destructive or uncontrolled testing without explicit written authorization
Explicit customer data-handling and retention terms
No implied self-hosting or unrestricted on-prem support unless specifically contracted and technically supported
Review HAIEC Trust & Security
Who Should Sponsor

Designed for a cross-functional enterprise decision.

CTO / VP Engineering

Question: Can we scale this AI architecture without carrying hidden action and access risk?

CISO / Product Security

Question: What can this AI-enabled system actually reach, and what technical evidence supports approval?

AI Platform / Architecture

Question: Where do identity, tools, APIs, deployment and agent capability diverge from intended design?

Risk / Compliance / AI Governance

Question: What technical evidence can support the control and governance record, and what remains unknown?

Procurement / Third-Party Risk

Question: What deeper technical evidence is available beyond questionnaires and vendor assertions?

Claim Boundary

Evidence before assertion.

HAIEC supports technical analysis, evidence collection and control mapping. It does not replace independent legal advice, regulatory determinations or third-party certification. A POC does not imply complete enterprise discovery, universal runtime visibility, a favorable finding, or proof beyond the evaluated evidence boundary.

Executive FAQ

The questions your board will ask.

What does a HAIEC Enterprise POC evaluate?

One consequential AI system and one primary assurance question. HAIEC maps supported action and access paths, correlates authority and control evidence across five independent planes (Requested, Policy Authorized, Effectively Granted, Code Capable, Observed), and delivers a bounded decision readout with explicit unknowns.

How long does the enterprise evaluation take?

Initial evaluations are commonly 4–8 weeks after the readiness date — after scope, evidence access, security approvals and commercial prerequisites are agreed. Fixed scope, fixed deliverable, no rolling extensions.

Does the POC require production access or telemetry?

No. The engagement follows a minimum-sufficient-evidence ladder: source and implementation artifacts, then control and authorization evidence. Runtime observation is optional and only when explicitly authorized. Where required, the evaluation can run fully inside your environment with telemetry disabled.

What happens when evidence is missing or incomplete?

It stays explicitly UNKNOWN in the report — never converted into a pass or a fail. The Evidence Frontier shows exactly where proof is established, partial, or unavailable, so decisions are made on what the evidence actually supports.

Qualification

Scope the right question first.

Tell us about the system, the decision you need to defend, and the evidence you can make available. HAIEC reviews fit and boundary before proposing a POC.

Step 1 — Required
Step 2 — Optional

Start with the decision you need to defend.

Start focused. One AI system, one assurance question. Establish what the evidence supports. Expand from there.

Typical scoped engagement: $25K–$75K. Initial evaluations are commonly 4–8 weeks after readiness. Final timing, evidence depth, testing authority and deliverables are defined in the SOW.