G01
Governance & lifecycleAI estate inventory completeness
Which AI systems and agents are actually in scope?
Evidence to inspectInventory / source discovery
Catalog profile · execution depends on source and test scope
HAIEC · PRACTICAL ENTERPRISE FIELD GUIDE
Your first 30 days of AI assurance.
A practical, self-paced plan to establish what one consequential AI system can do, what it is authorized to do, what has actually happened, and what the evidence supports. Then decide what the enterprise should do next.
30Guided daily actions
45Catalog entries, including C7/C9/C16
9DAI dimensions explained
4Operational monitoring lenses
YOUR LEARNING PATH
Four weeks. One defensible decision.
Each week produces a concrete artifact or a clearly qualified evidence gap. You can enter at any point that fits your authorized goal.
FIRST PRINCIPLES
What you are actually establishing
UNDERSTAND
See the consequence
Map the AI system, principals, tools, data and possible action-to-business-effect paths, using source-qualified relationships.
ASSURE
Compare the evidence
Test supported controls and compare request, policy, effective grants, code reachability and observation independently.
GOVERN & OPERATE
Act with accountability
Assign real human decisions, monitor what sources can show, connect native controls where needed and verify the report trail.
Designed for two entry modes. Explore using public example reports, or work in your organization with genuine role, source, and evaluation permissions. Completing a lesson is not an HAIEC evaluation or product approval. The six capabilities can be used independently and the 30-day sequence is not a prerequisite checklist.
ONE RECURRING SCENARIO
A purchasing agent with more reach than intended
The example teaches what code, credentials, policy, discretionary choice and observation each reveal. Specific numbers below are illustrative teaching values, not HAIEC findings.
Business requestProcess a permitted purchase under policy limits
Agent + toolInvoke procurement tool through a callable handler
Effective accessService credential may reach broader write API
Target outcomePurchase record changes only if dispatched and applied
A reachable write path is useful security evidence even if no runtime event is present. Approval, effective grant, delegation, dispatch and independently witnessed effect each require their own support.
YOUR LEARNING JOURNEY
30 days, built for real operating decisions
Every day includes a why, a safe activity, the evidence boundary and something worth recording. Jump around if you already have a source, policy or report.
0 days recorded
Progress is held in this browser tab until you export it. No notes are sent anywhere.
01Choose the consequential AI questionOne-sentence assurance question and scopeNot started
Why this mattersAI assurance becomes actionable when tied to an identifiable business consequence.
Your activityPick one system and one protected action. Write the actor, operation, resource, environment, consequence, explicit exclusions and who needs an answer.
Evidence boundaryA description of the use case is a declaration, not proof of code reachability or execution.
Record your outputOne-sentence assurance question and scope
Your workbook response (optional, non-sensitive)
Relevant catalog controls: G01,G0202Identify owners and testing authorityScope and RACI-lite owner recordNot started
Why this mattersWithout named human accountability, risk results have no reliable decision path.
Your activityAssign sponsor, AI system owner, security reviewer, source/IAM steward, authorized decision owner and operations lead. Identify who may approve source access and testing.
Evidence boundaryA named owner is not equivalent to an approved operating envelope or production test authorization.
Record your outputScope and RACI-lite owner record
Your workbook response (optional, non-sensitive)
Relevant catalog controls: G02,G03,A0603Choose your starting pointSelected entry path and first permitted actionNot started
Why this mattersHAIEC supports system-first, goal-first and source-first onboarding.
Your activityChoose one path. In Explore mode inspect the public Kestrel example; in Workspace mode check your actual role, organization, entitlement and existing system.
Evidence boundaryAn accessible sample does not imply you can write or evaluate in your own organization.
Record your outputSelected entry path and first permitted action
04Establish a bounded system recordSystem ID or labeled sample contextNot started
Why this mattersThe system boundary is necessary to interpret findings later.
Your activityIdentify one AI System, agent/tool, deployment environment, ownership and target of consequence. Reuse an existing record or create one only with permission.
Evidence boundaryA system registration is not a verified source or a completed evaluation.
Record your outputSystem ID or labeled sample context
Your workbook response (optional, non-sensitive)
Relevant catalog controls: G01,G0205Trace high-impact tool actionsOne action-and-consequence mapNot started
Why this mattersThe main risk may reside in the tool/API consequence, not in the language-model answer.
Your activityTrace agent → tool → handler → API → target for one critical action. Mark each relationship established by source, candidate, or absent.
Evidence boundaryReachable code or displayed topology does not prove the call executed in production.
Record your outputOne action-and-consequence map
Your workbook response (optional, non-sensitive)
Relevant catalog controls: S01,A02,R0106Qualify the first evidence sourceSource register with qualification and freshnessNot started
Why this mattersOne qualified input can support an early useful finding.
Your activityInventory possible repository, SARIF, policy, IAM, telemetry, API source or uploaded declaration. Select the least-privileged eligible source and note identity and consent.
Evidence boundaryConfigured, connected, evidence received and evaluated are separate states. Missing sources do not make known findings disappear.
Record your outputSource register with qualification and freshness
Your workbook response (optional, non-sensitive)
Relevant catalog controls: E01,E0307Week-one evidence checkpointDay 7 baseline summaryNot started
Why this mattersStart with what is established, not an all-green dashboard.
Your activityExplain your top source-backed finding, source limitation, business consequence and the next smallest evidence action. If none exists, name the precise access blocker.
Evidence boundaryThis checkpoint is a teaching milestone, not an engine certification or mandatory product stage.
Record your outputDay 7 baseline summary
Your workbook response (optional, non-sensitive)
Relevant catalog controls: G01,E0108Prioritize AI attack pathwaysTwo qualified threat questions and safe test proposalNot started
Why this mattersThreat families become meaningful when tied to reachable consequences.
Your activityConsider prompt injection, tool forcing, RAG/data exfiltration, tenant crossing, secrets, supply-chain and model/output failure. Pick the most relevant two hypotheses.
Evidence boundaryA listed attack category is not a tested or exploited vulnerability.
Record your outputTwo qualified threat questions and safe test proposal
Your workbook response (optional, non-sensitive)
Relevant catalog controls: S02,S03,S04,S05,S06,L0109Compare five evidence planesFive-plane evidence matrixNot started
Why this mattersPolicy, grants, code capability and observation can contradict one another.
Your activityFor Requested, Policy Authorized, Effectively Granted, Code Capable and Observed, record actual source, as-of date and one claim the plane can support.
Evidence boundaryThe five planes are not five required connections or stages, and none can substitute for another.
Record your outputFive-plane evidence matrix
Your workbook response (optional, non-sensitive)
Relevant catalog controls: A01,A02,E0310Inspect code capability and reachabilityProven versus candidate action-path analysisNot started
Why this mattersEvidence-bound reachability helps identify a material risk before runtime is connected.
Your activityInspect tool registration, handler, reachable resource, target and error/mediation path. Separate candidate-only mapping from established source edge.
Evidence boundaryCode Capable means potentially reachable in analyzed scope, not executed or authorized.
Record your outputProven versus candidate action-path analysis
Your workbook response (optional, non-sensitive)
Relevant catalog controls: A02,S01,R0111Learn DAI and delegated choiceDAI worksheet with known/unknown dimensionsNot started
Why this mattersA credential can permit an action without showing who authorized an AI to make that choice.
Your activityCompare nine DAI dimensions. Ask whether approved policy already resolves a fixed business rule or if residual discretionary choice needs qualified delegation evidence.
Evidence boundaryMissing delegated evidence is not a demonstrated delegation violation. ISAF v2 research semantics are not all implemented in current DAI v1.
Record your outputDAI worksheet with known/unknown dimensions
Your workbook response (optional, non-sensitive)
Relevant catalog controls: A01,A03,A06,A0812Choose applicable controlsScoped controls shortlist and test basisNot started
Why this mattersEffective controls review begins with material risk and actual eligible sources.
Your activityChoose two to four controls from the complete 45-entry atlas; record source required, applicability, whether a test ran and the result if available.
Evidence boundaryCataloged does not mean implemented, tested, evaluated or enforced on a customer target.
Record your outputScoped controls shortlist and test basis
Your workbook response (optional, non-sensitive)
Relevant catalog controls: A02,A03,R02,E0113Inspect a frozen assurance evaluationReal evaluation reference or exact execution blockerNot started
Why this mattersA persisted evaluation provides a bounded decision basis.
Your activityOpen a selected report, or perform one consented eligible run. Capture exact evaluation ID, source snapshot, analyzer execution, scope, disposition and limitations.
Evidence boundaryALLOW/REVIEW/BLOCK is not a human deployment approval, universal safe verdict or verified external effect.
Record your outputReal evaluation reference or exact execution blocker
Your workbook response (optional, non-sensitive)
Relevant catalog controls: E01,E0514Week-two assurance checkpointIn-scope assurance baselineNot started
Why this mattersThe right result is what evidence supports, including meaningful gaps.
Your activityExplain source findings, DAI/control applicability, actual executed tests and high-impact unknowns. Record one decision affected by the evidence.
Evidence boundaryNot assessed is not a pass. A missing runtime source does not erase a source-supported exposure.
Record your outputIn-scope assurance baseline
Your workbook response (optional, non-sensitive)
Relevant catalog controls: E03,E04,E0515Classify material findingsFinding register with exact evidence refsNot started
Why this mattersAn exposure, unauthorized action, source gap and failed control require different responses.
Your activityGroup your issues by reachable capability, policy/grant mismatch, DAI/identity, observed policy drift, control effectiveness and missing source.
Evidence boundaryDo not mark a merely absent producer as an actual policy violation.
Record your outputFinding register with exact evidence refs
Your workbook response (optional, non-sensitive)
Relevant catalog controls: A01,A03,R02,E0416Prioritize consequences and remediationTop three prioritized issuesNot started
Why this mattersSeverity depends on actual consequence, reachability, authority and source credibility.
Your activityRank material issues by impact, established path, source confidence, affected target, reversibility, responsible owner and available remedy.
Evidence boundaryA single high score or heatmap cannot replace the evidence and time basis.
Record your outputTop three prioritized issues
Your workbook response (optional, non-sensitive)
Relevant catalog controls: G04,R0217Inspect approved policy and operating scopePolicy version, decision owner and limitsNot started
Why this mattersPolicy constrains permitted operations, not necessarily the effective credential or agent discretion.
Your activityLocate intended action, limit, recipient/target, business owner, environment and validity period. Distinguish DRAFT from APPROVED.
Evidence boundaryApproved policy is real policy evidence; it does not automatically prove executed mediation or agent delegation.
Record your outputPolicy version, decision owner and limits
Your workbook response (optional, non-sensitive)
Relevant catalog controls: G03,A01,A0618Practice human governanceReal/pending decision record or learning responseNot started
Why this mattersConsequence ownership requires a traceable human decision.
Your activityReview an authentic request where allowed. Record approve, reject, defer, revoke or request evidence as the actual system permits; otherwise work through a labeled case.
Evidence boundaryThe workbook never submits approvals; a reviewer decision is not proof a customer guard blocked or permitted an action.
Record your outputReal/pending decision record or learning response
Your workbook response (optional, non-sensitive)
Relevant catalog controls: A06,G0319Assign treatment actionsTreatment owner, verification method and triggerNot started
Why this mattersA finding matters only when its owner knows the next legitimate step.
Your activityChoose between reducing IAM grants, fixing source code, adjusting business policy, approving a scoped exception, adding a source or testing a guard.
Evidence boundaryRecommendation is not remediation. Separate customer-owned change from HAIEC evaluation.
Record your outputTreatment owner, verification method and trigger
Your workbook response (optional, non-sensitive)
Relevant catalog controls: A07,S01,R0320Understand actual protection coverageProtection readiness and integration dependenciesNot started
Why this mattersA configured guardrail differs from an interception and independently verified effect.
Your activityInspect four links: governed decision, customer enforcement point, permitted/denied dispatch and target-state readback. Choose a supported integration pilot only if needed.
Evidence boundaryUnwired PEP stays NOT_WIRED; monitoring/approval alone is not universal runtime protection.
Record your outputProtection readiness and integration dependencies
Your workbook response (optional, non-sensitive)
Relevant catalog controls: R03,R04,R0521Week-three human decision checkpointGovernance decision packet and issue ownershipNot started
Why this mattersThe customer needs an accountable judgment and a proportionate next step.
Your activityPresent a short packet: what was requested, which code/grants exist, what was observed, the open evidence gaps, the affected consequence and owner.
Evidence boundaryThe milestone is about responsible human review, not a generated certificate of safe deployment.
Record your outputGovernance decision packet and issue ownership
Your workbook response (optional, non-sensitive)
Relevant catalog controls: G02,G03,A0622Interpret monitoring source healthSource health and continuity matrixNot started
Why this mattersA historical event does not mean a source is delivering now.
Your activityReview NOT_CONFIGURED, NO_SIGNAL, DELIVERING, STALE, FRESHNESS_UNKNOWN and DEGRADED. Record source identity, expected cadence, last qualified receipt and owner.
Evidence boundaryConfigured is not delivering; a stale receipt cannot support current activity claims.
Record your outputSource health and continuity matrix
Your workbook response (optional, non-sensitive)
Relevant catalog controls: R07,E0223Compare events, alerts and target effectsEvent-to-action evidence chain with unknownsNot started
Why this mattersSignals, observed invocations, acknowledgment and applied target changes are separate facts.
Your activityFollow one action request to correlation ID, telemetry source, alert, reviewer ACK and independent target-state readback where connected.
Evidence boundaryHTTP 200 or ingested trace alone does not prove a business side effect; alert delivery does not prove human ACK.
Record your outputEvent-to-action evidence chain with unknowns
Your workbook response (optional, non-sensitive)
Relevant catalog controls: R01,R02,E0324Run an incident response tabletopResponse chronology and actual/potential actionsNot started
Why this mattersResponse is a human-owned workflow, not an automatic green badge.
Your activityExercise safe scenario: stale source, suspicious privileged tool event, triage, decision owner, hold/deny feasibility, notification, containment, recovery and later re-evaluation.
Evidence boundaryAn educational tabletop does not claim a real incident or tested kill switch.
Record your outputResponse chronology and actual/potential actions
Your workbook response (optional, non-sensitive)
Relevant catalog controls: R04,R05,R0625Define what triggers re-evaluationChange trigger, owner and review cadenceNot started
Why this mattersAssurance gets stale when source code, authority or operational conditions change.
Your activityCreate triggers for source version, tool capability, policy approval, IAM principal, deployment environment, provider, evidence freshness and material incident.
Evidence boundaryA scheduled reminder does not replace fresh admitted evidence and a new evaluation.
Record your outputChange trigger, owner and review cadence
Your workbook response (optional, non-sensitive)
Relevant catalog controls: G07,R07,E0526Compare two source or release statesQualified before/after change noteNot started
Why this mattersA code diff and an assurance consequence change are not the same.
Your activityWhere eligible, compare exact frozen releases and analyzer/source coverage. Alternatively inspect public Kestrel release comparison with its inconclusive facets.
Evidence boundaryIncomparable or incomplete coverage must not become a false removed-path claim.
Record your outputQualified before/after change note
Your workbook response (optional, non-sensitive)
Relevant catalog controls: G07,E0527Assemble an assurance reportReport link and evidence ledgerNot started
Why this mattersReviewers need a coherent claim/source/limit/decision chain.
Your activityUse actual completed evaluation details to assemble executive summary, technical finding, source evidence, DAI/control scope, unresolved items and owner.
Evidence boundaryA polished report does not manufacture execution evidence, full scope or a legal certification.
Record your outputReport link and evidence ledger
Your workbook response (optional, non-sensitive)
Relevant catalog controls: E01,E03,E0428Verify the report and receiptReceipt reference or NOT_ISSUED and next verification stepNot started
Why this mattersIntegrity and source validity answer different questions.
Your activityInspect actual report/evaluation ID, receipt or package visibility, digest, public/private/revoked state and exact as-of basis, if issued.
Evidence boundaryValid receipt lineage does not independently prove every upstream IAM or runtime source fact.
Record your outputReceipt reference or NOT_ISSUED and next verification step
Your workbook response (optional, non-sensitive)
Relevant catalog controls: E01,E0529Plan the next 30/60/90 daysOwner-assigned follow-on roadmapNot started
Why this mattersA durable operating program has clear owners and verifiable objectives.
Your activityPrioritize high-impact evidence gaps, controls, IAM, monitoring, source continuity, report recurrence and any real customer-native target integration.
Evidence boundaryOptional enterprise services only add scoped value; they are not needed to make the native evaluator correct.
Record your outputOwner-assigned follow-on roadmap
Your workbook response (optional, non-sensitive)
Relevant catalog controls: G07,R0730Present a defensible executive decisionDay-30 executive readoutNot started
Why this mattersThe outcome is clarity about what HAIEC established, what remains uncertain and what the enterprise will do.
Your activityPresent before versus after evidence, consequential risks, exact evaluations and receipts, human decisions, monitoring readiness and the next agreed actions.
Evidence boundaryA 30-day curriculum is not a certification, fixed service-level deadline or proof that an unwired target was protected.
Record your outputDay-30 executive readout
Your workbook response (optional, non-sensitive)
Relevant catalog controls: G02,G04,E01METHOD · ISAF V2 · DAI
An AI action has several different truths
Authorization and ability can diverge. ISAF v2 supplies a research/methodological framework. HAIEC's shipping DAI engine has its own bounded implemented comparator and should not be presented as every proposed ISAF v2 capability.
A source can establish a strong code-path finding before all five planes are populated. Treat each evidence plane as an independent question, not a required integration step or substitute for another plane.
01Requested
What operation was asked for?
Evidence: Prompt, request, ticket or tool inputA request is not approval.02Policy Authorized
What explicit policy permits?
Evidence: Approved business/operating envelopePolicy does not imply current IAM grant.03Effectively Granted
What privileges are available?
Evidence: Provider-issued IAM/principal evidenceIAM does not prove the agent used the grant.04Code Capable
What could implementation reach?
Evidence: Source/tool/call graphReachability is not execution.05Observed
What is witnessed in scope?
Evidence: Qualified runtime/action telemetryA trace does not prove downstream business effect alone.DELEGATED ACTION INTEGRITY
Nine dimensions of a consequential choice
A credential may enable a broad operation. Did approved policy fix the choice, or did an agent exercise independent discretion needing qualified delegation evidence? The answer depends on exact sources, scope and time.
01OperationWhich action or API operation?
02TargetWhich resource, service or record?
03ScopeWhich objects, accounts or tenants?
04MagnitudeWhat amount, count or scale?
05DurationHow long is the grant or action valid?
06ApprovalWhich qualified human or policy authorization?
07Data classWhat sensitivity/classification?
08EnvironmentDevelopment, test or production?
09GeographyWhich region or jurisdiction?
Policy vs grant vs delegated choice
A written $500 refund limit is relevant policy evidence. A $10,000 API permission is a separate grant. A reachable refund handler establishes code capability. Whether an agent chose an amount under qualified discretionary authority is a further question. A tool response alone does not verify that funds moved.
Missing delegated authority evidence is not itself proof of an unauthorized delegated action. Preserve valid policy and code findings while making unresolved facets explicit.
Evidence / effect frontier
At each claimed link, ask: Who asserted it? Which actor and system? Which environment? What time? Is the source identity qualified? Was action merely requested, enabled by code, sent, observed or independently read back at the target?
Cross-system delegation and target proof must be labeled unverified where the required per-hop identity, issuer and correlation facts are not established.
Read the HAIEC methodology ↗IMPLEMENTED DAI STATUS VOCABULARY
Seven bounded DAI result states
INSIDE_ESTABLISHED_DELEGATIONSupported facts are within a qualified delegated scope.CAPABILITY_OUTSIDE_DELEGATION_MEDIATEDA broader reachable capability exists, with source-backed mediation evidence.CAPABILITY_OUTSIDE_DELEGATION_UNMEDIATEDA broader reachable capability exists without the required established mediation.GRANT_BROADER_THAN_DELEGATIONProvider grant exceeds established delegated scope.OBSERVED_OUTSIDE_DELEGATIONQualified observed action exceeds established delegation.UNRESOLVED_DELEGATION_EXPOSURESome relevant delegated comparison remains unresolved.NOT_ASSESSEDRequired delegation evidence is absent for assessment.EVIDENCE EXERCISE
What does a wider credential actually prove?
An agent has a source-backed path to modify purchase records, and a verified service principal has a broad write grant. You have no qualified runtime event and no independent purchase-record readback. Choose the strongest answer:
Choose an option to see the evidence interpretation.
ASSURANCE CONTROL ATLAS
All 45 current catalog entries
Complete searchable inventory of seven control families and three specialized tests. Each entry includes its question and intended evidence source. Use a shortlist to focus on 2–4 controls relevant to your selected action.
Counting correctly: 45 total entries includes specialized C7, C9 and C16, plus 42 profiles across seven lettered families. Fifteen entries carry launch-priority metadata; 11 are listed in a specific visibility projection. None of those counts establishes execution, an evaluated control result, or customer-native enforcement.
45 of 45 controls
Control evaluation ladder
Cataloged → applicable → relevant source available → test specified → executed → evaluated/recorded → independently verified where possible. Target-side enforcement is a distinct additional proof question.
How to use these profiles
Ask the listed question, connect the smallest qualifying evidence, inspect actual execution status and record limitation, owner and next action. Never claim all 45 were tested because they appear here.
Shortlisted in this session: 0
G02
Governance & lifecycleAccountable ownership and responsibility
Who is accountable for the AI system and its decisions?
Evidence to inspectGovernance records
Catalog profile · execution depends on source and test scope
G03
Governance & lifecycleAI acceptable use and approval
Has the use case and operating scope been approved?
Evidence to inspectApproved use policy
Catalog profile · execution depends on source and test scope
G04
Governance & lifecycleAI risk and impact assessment
What risks and impacts were assessed before use?
Evidence to inspectRisk registry
Catalog profile · execution depends on source and test scope
G05
Governance & lifecycleRegulatory applicability and obligations
Which obligations apply to this deployment?
Evidence to inspectFramework mappings
Catalog profile · execution depends on source and test scope
G06
Governance & lifecycleThird-party AI and vendor assurance
Are model, provider and upstream risks evaluated?
Evidence to inspectVendor inventory
Catalog profile · execution depends on source and test scope
G07
Governance & lifecycleChange and lifecycle governance
Can governance scope be linked to system changes?
Evidence to inspectBuild provenance / CI
Catalog profile · execution depends on source and test scope
S01
Application & tool securityPrivileged tool authorization paths
Can privileged tools bypass approved mediation?
Evidence to inspectStatic security analysis
Catalog profile · execution depends on source and test scope
S02
Application & tool security PriorityMulti-tenant isolation
Are tenant identity and data accesses correctly scoped?
Evidence to inspectTenant-isolation analyzer
Catalog profile · execution depends on source and test scope
S03
Application & tool security PriorityMCP and tool exposure
Are tool capabilities exposed beyond intended authority?
Evidence to inspectMCP / AI AppSec analysis
Catalog profile · execution depends on source and test scope
S04
Application & tool security PrioritySecrets and credential protection
Could agents expose or misuse secrets?
Evidence to inspectStatic and LLM heuristics
Catalog profile · execution depends on source and test scope
S05
Application & tool security PriorityPrompt and input trust boundaries
Do untrusted inputs cross into privileged instructions?
Evidence to inspectStatic and runtime probes
Catalog profile · execution depends on source and test scope
S06
Application & tool securityRAG retrieval and exfiltration paths
Can retrieval cross trust or data boundaries?
Evidence to inspectRAG / dataflow analysis
Catalog profile · execution depends on source and test scope
S07
Application & tool securitySecure AI SDLC and build provenance
Can source, artifacts and release lineage be established?
Evidence to inspectCI / SARIF provenance
Catalog profile · execution depends on source and test scope
A01
Agent authority & delegation PriorityExcessive effective authority
Does effective access exceed approved authority?
Evidence to inspectFive-plane IAM / policy
Catalog profile · execution depends on source and test scope
A02
Agent authority & delegation Priority Visibility projectionUndeclared executable capability
Can analyzed code reach an operation outside its approved scope?
Evidence to inspectStatic source / five-plane evidence
Catalog profile · execution depends on source and test scope
A03
Agent authority & delegation Priority Visibility projectionDelegated Action Integrity
Does delegated authority cover the intended, granted and observed action?
Evidence to inspectDAI nine dimensions
Catalog profile · execution depends on source and test scope
A04
Agent authority & delegation Priority Visibility projectionObserved action outside approved policy
Was an action observed beyond its approved envelope?
Evidence to inspectQualified action witness
Catalog profile · execution depends on source and test scope
A05
Agent authority & delegation Priority Visibility projectionAgent and principal identity continuity
Is the runtime principal authoritatively bound to the agent?
Evidence to inspectIdentity continuity
Catalog profile · execution depends on source and test scope
A06
Agent authority & delegation Priority Visibility projectionHuman approval and mediation integrity
Was required human authorization applied at the action boundary?
Evidence to inspectApproval / mediation
Catalog profile · execution depends on source and test scope
A07
Agent authority & delegationLeast privilege and unused grants
Do granted privileges exceed required capabilities?
Evidence to inspectIAM plus capability
Catalog profile · execution depends on source and test scope
A08
Agent authority & delegation Visibility projectionCross-agent delegation propagation
Was authority preserved across A2A handoffs?
Evidence to inspectDelegation lineage
Catalog profile · execution depends on source and test scope
R01
Runtime & consequencesAction lifecycle and side-effect traceability
Can request, authorization and applied effect be reconciled?
Evidence to inspectAction lifecycle witness
Catalog profile · execution depends on source and test scope
R02
Runtime & consequences Priority Visibility projectionConsequential effect envelope
Were measured side effects within approved magnitude and scope?
Evidence to inspectEffect bound comparator
Catalog profile · execution depends on source and test scope
R03
Runtime & consequences Visibility projectionRuntime guardrail enforcement evidence
Did a declared guardrail actually enforce a decision?
Evidence to inspectDecision + denial witness
Catalog profile · execution depends on source and test scope
R04
Runtime & consequencesEmergency intervention effectiveness
Did a kill-switch action actually stop execution?
Evidence to inspectKill-switch witnesses
Catalog profile · execution depends on source and test scope
R05
Runtime & consequencesRecovery and resumption authorization
Was recovery governed and attributable?
Evidence to inspectRecovery audit
Catalog profile · execution depends on source and test scope
R06
Runtime & consequencesAI incident response and recovery
Can material AI incidents be investigated and recovered?
Evidence to inspectIncident workflow
Catalog profile · execution depends on source and test scope
R07
Runtime & consequencesContinuous runtime monitoring
Are sources sufficiently complete to detect relevant events?
Evidence to inspectOTel and source continuity
Catalog profile · execution depends on source and test scope
L01
LLM safety & reliabilityPrompt-injection resistance under test
How does the system respond to scoped adversarial prompts?
Evidence to inspectRuntime / LLMVerify
Catalog profile · execution depends on source and test scope
L02
LLM safety & reliabilitySensitive output leakage
Did tested responses expose protected information?
Evidence to inspectPII / secret signal
Catalog profile · execution depends on source and test scope
L03
LLM safety & reliabilityHallucination risk and grounding
What evidence supports content grounding reliability?
Evidence to inspectLLMVerify heuristics
Catalog profile · execution depends on source and test scope
L04
LLM safety & reliabilityUnsafe output risk
What harmful-output risks were detected in tested scenarios?
Evidence to inspectLLM risk indicator
Catalog profile · execution depends on source and test scope
L05
LLM safety & reliabilityStructured output and consistency
Do generated responses meet a specified output contract?
Evidence to inspectSchema / consistency
Catalog profile · execution depends on source and test scope
E01
Evidence & audit Priority Visibility projectionEvidence integrity and provenance
Can we verify evidence origin, binding and modification?
Evidence to inspectEvidence Core
Catalog profile · execution depends on source and test scope
E02
Evidence & auditEvent stream coverage and continuity
Is telemetry coverage complete enough for the claimed window?
Evidence to inspectOTel continuity
Catalog profile · execution depends on source and test scope
E03
Evidence & audit Visibility projectionSource authority and plane correlation
Are identity, system and action joins source-qualified?
Evidence to inspectEnvironment binder
Catalog profile · execution depends on source and test scope
E04
Evidence & auditContradiction and source reconciliation
Do independent sources disagree or lack reconciliation?
Evidence to inspectEvidence projections
Catalog profile · execution depends on source and test scope
E05
Evidence & audit Visibility projectionIndependent deterministic replay
Can another verifier reproduce the exact frozen result?
Evidence to inspectReplay manifest
Catalog profile · execution depends on source and test scope
P01
Responsible AIBias and fairness evaluation coverage
Were affected groups and relevant harms assessed?
Evidence to inspectBias testing
Catalog profile · execution depends on source and test scope
P02
Responsible AITransparency and explainability
Can users and owners understand reasons and limitations?
Evidence to inspectDocumentation review
Catalog profile · execution depends on source and test scope
P03
Responsible AITraining data governance and lineage
Is training data provenance established and reviewable?
Evidence to inspectISAF lineage
Catalog profile · execution depends on source and test scope
C7
Specialized tests PriorityAudit trail completeness
Are required audit categories captured under a frozen policy?
Evidence to inspectSpecialized C7 test
Specialized scoped test · execution depends on source and test scope
C9
Specialized tests PriorityDuration anomaly threshold
Does measured duration meet the bounded frozen policy?
Evidence to inspectSpecialized C9 test
Specialized scoped test · execution depends on source and test scope
C16
Specialized tests PriorityToken expenditure cap
Does measured token expenditure satisfy the frozen cap?
Evidence to inspectSpecialized C16 test
Specialized scoped test · execution depends on source and test scope
No controls match that filter.
MONITOR · PROTECT · INCIDENT RESPONSE
Know what is observed, operating and enforced
HAIEC separates monitoring into four independently supported lanes. A result in one lane does not automatically establish another. Use these views to design a practical on-call operating loop.
Passive telemetry and source health
Are qualified sources delivering now?
Check declared cadence, last accepted qualified receipt, identity, freshness, quarantine, retention, coverage and a responsible source owner.
Do not infer: Configured ≠ delivering; stale history is not current coverage.
Owner view: Sources and TelemetryAuthorized tests and detections
What actually ran, and with what coverage?
Check test authorization, category selectability, execution, analyzer identity, finding basis, NOT_RUN/HELD, related vulnerability hypotheses and source-vs-runtime distinction.
Do not infer: Cataloged tests and rule registrations are not executed findings.
Owner view: Runtime Tests and RisksApproved policy and decision state
Who authorized the envelope or response?
Check approval/version, human decision actor, DAI contradictions, policy change, scope limits, alert case and human ACK.
Do not infer: Policy configured or notification delivered is not target enforcement or acknowledged response.
Owner view: Guardrails and My WorkNative target enforcement and effect
What was actually intercepted and applied?
Check customer target adapter/PEP status, exact allow/deny/hold, decision binding, no-bypass, dispatch receipt, readback and recovery authority.
Do not infer: NOT_WIRED is not protected; approval is not a verified target side effect.
Owner view: Enforcement and GovernanceSIGNAL STATE TEACHING REFERENCE
Six monitoring-readiness states
Monitor source identity, expected cadence, last qualified receipt, source failures and production relevance; never mistake a configured endpoint or historical receipt for current telemetry.
| Source overview | What it means in context | Question to ask |
|---|---|---|
| NOT_CONFIGURED | No eligible source configured | Do we need this source for the selected claim? |
| NO_SIGNAL | Source known or configured but no qualifying delivered signal | Is the owner, endpoint or consent ready? |
| DELIVERING | At least one freshness-qualified source is delivering within declared cadence | Which producer, which interval and which system/action coverage? |
| STALE | Qualified historic source exists but is older than its declared interval | What was missed after its last trusted receipt? |
| FRESHNESS_UNKNOWN | Receipts/cadence do not qualify current freshness | Is the expected reporting cadence independently established? |
| DEGRADED | Source quarantine, read failure or relevant degraded state | What is the failure owner and recovery evidence? |
RUN THE OPERATING LOOP
Incident response that preserves evidence
Establish source healthQualified actor, producer, system identity and event window.
Detect and triageSeparate actual executed test/finding from catalog coverage.
Correlate authorityRequested, policy, grants, DAI and observed event scope.
Notify accountable ownerDelivery and human acknowledgment remain distinct.
Decide interventionHuman approval, treatment and required target integration.
Confirm effectCheck actual interception/dispatch and independent target readback.
Recover and revalidateGoverned resumption, test negative path and renew proof.
Report and monitorFreeze basis and track code/identity/policy/source change triggers.
For safe learning, do not run effect-capable adversarial tests on live targets without explicit permission and adequate confinement. The runtime testing page distinguishes selectable catalog categories from actual executed test coverage.
GOVERNANCE · REPORTS · VERIFICATION
From qualified findings to accountable decisions
Decisions, human authorization, native enforcement and report verification are separate responsibilities. This is where assurance influences business action without overstating what was tested.
Human decision packet
What to present: the action/consequence and environment, exact source-backed code path, relevant policy and IAM state, DAI unknowns, applicable controls and actual test status.
Who decides: an authorized reviewer may approve, reject, request more evidence, defer or revoke within actual HAIEC/customer workflows. Record reviewer, reason, scope and as-of date.
A policy approval is not a target-side allow/deny witness. Do not use the workbook to submit real approval.
Verification and receipt lineage
Inspect: selected exact Evaluation ID, frozen source snapshot, analyzer execution, claim/evidence links, report scope, package/receipt integrity and public/private/revoked state.
Do not equate: receipt integrity with certification or independent proof of every upstream provider claim. Missing sources and contradictory facts should remain visible.
Evidence and provenance ↗ASSURANCE CONTINUITY
Seven questions for a defensible governance review
- Which business action, system, target and environment were in scope?
- Which source-qualified paths were found, and which were candidate-only?
- What approved policy governed the consequence, and what grants existed?
- Which delegated-choice questions and nine DAI facets remain unresolved?
- Which controls and tests actually ran, with what observed outcomes?
- What human decision, actual target guard and effect proof exist, if any?
- Which report/receipt records preserve the result, and what events trigger reassessment?
DAY-30 EXECUTIVE READOUT
Present outcomes, not an invented overall score
NOW
What was established from qualified evidence? What material unknowns remain? Which issue changed a decision?
30 DAYS
Close one actionable evidence/control gap, assign treatment owners and trigger reviews on source change.
60–90 DAYS
Expand only where the next source or native integration can demonstrably add material coverage or effect proof.
ISAF v2 methodology and frameworks such as NIST AI RMF, ISO/IEC 42001, SOC 2 and OWASP may inform relevant questions. A control-to-framework mapping is not third-party certification, proof of a specific legal obligation or automatic regulatory compliance.
SOURCES · INTEGRATIONS · DEVELOPER EXPERIENCE
Connect only what the evidence question needs
Developer access to HAIEC through MCP/API is different from connecting upstream evidence producers such as GitHub, cloud IAM or telemetry. Each integration has a distinct authorization and qualification contract.
GitHub and code source
Qualify repository identity, installation/consent, source revision and analyzer execution. Trace tool handlers and code-capable consequences.
Source capabilityPolicy and IAM
Use approved policy and relevant IAM/provisioned principals to compare permitted and effective access where source qualification supports it. Cloud policy simulation alone does not prove all effective grants.
Partial authority evidenceOpenTelemetry / events
Connect qualified OTLP, logs, traces and structured events to support bounded observed behavior and signal freshness. Collector receipt alone is not target effect.
Operational evidenceAWS / cloud services
Read scope-limited cloud/provider identity, policy and available AgentCore/CloudWatch sources where integration and entitlements permit. Keep unqualified joins unknown.
Source-specificServiceNow / ITSM
Use supported instance and table evidence for ownership, response and governance where connected. Ticket data and approval notifications do not automatically prove protected dispatch.
Workflow evidenceSecurity and local tools
AI AppSec, MCP Tenant Isolation, LLMVerify, CI/SARIF and local bounded analysis can provide source/test artifacts. Package results are not automatically the full SaaS evaluation.
Independently scopedMCP QUICK GUIDE
Let your AI assistant guide the workflow
Use a supported coding agent or IDE to interact with HAIEC's scoped MCP surface, while HAIEC remains the deterministic evaluator.
Authorized client→HAIEC MCP preflight→Eligible AI System + source→Consented evaluation→Exact report and follow-up
The example intent “Run HAIEC AI Assurance” is not permission for an unconditional scan. HAIEC MCP uses a scoped Bearer API key, checks organization/source readiness and needs the required user approvals and idempotency for supported actions. It does not grant third-party cloud credentials.
YOUR LOCAL EVIDENCE WORKBOOK
Turn the learning into an accountable plan
These eleven progressive worksheets are optional. Record only non-sensitive summaries and references to genuine HAIEC results. You can export them as a Markdown file directly from this browser. Nothing is sent to a server by this HTML.
Do not enter passwords, tokens, private logs, confidential code, personal data or sensitive customer evidence. These fields are local notes, not a HAIEC source ingestion, validated policy or control result.
A01
Scope and decisionBusiness consequence, system/environment, owner, exclusions and primary assurance question.
A02
Source and consentSelected evidence source, qualification status, identity/consent, as-of and source owner.
A03
Five-plane assessmentA separate fact and limitation for each of Requested, Policy, Granted, Code and Observed.
A04
DAI assessmentNine-dimensional delegated choice question, source evidence, mediation and unresolved facets.
A05
Controls shortlistApplicable control IDs, source needed, catalog/test/evaluation status, owner and next test.
A06
Assurance baselineReal evaluated system/run/ID, source digest, executed analyzer, result and unresolved items, or NOT_RUN.
A07
Human governancePolicy version, reviewer, decision scope/status and treatment. No invented approval.
A08
Operational monitoringActual source freshness, alert delivery/ACK, detection coverage, incident and response owner.
A09
Protection/effectIs a target guard wired, tested and enforced? Is independent effect readback available?
A10
Evidence and verificationExact report/receipt reference, publication status, provenance and limitations.
A11
Next 30/60/90 daysPriorities, owner, due cadence, new source evidence, control retest and review conditions.
SELF-CHECK · PRACTICAL UNDERSTANDING
Six questions worth getting right
These scenarios test the boundaries between capability, authorization, observation, control coverage, human decision and verification. Answers provide immediate explanations.
Select an answer to each question, then check your reasoning.
DIRECT OFFICIAL REFERENCES
Continue with the actual HAIEC product
Public references are available to explore. Several workspace routes require login, actual entitlement and authorized organization membership. Source and report availability can change over time.
Enterprise Assurance ↗
Scope, consequence-driven engagements and evidence access ladder.
Start Here ↗
Find the supported entry path for a system, goal or evidence source.
Methodology ↗
Five planes and bounded deterministic conclusions.
Assurance Controls ↗
Control questions, status and evidence concepts.
Evidence and Provenance ↗
Source, time, scope, coverage and qualified limitations.
MCP Agent Integration ↗
Client/key setup, preflight and authorized evaluation.
Runtime Testing ↗
What authorized behavioral tests can and cannot show.
Sample Reports ↗
Current, historical and illustrative reports labeled by source type.
Kestrel Evidence-Bound Case ↗
Real-repository evaluation with explicit missing authority/observation limits.
Kestrel Release Comparison ↗
How qualified differences and unresolved changes can coexist.
Technical Documentation ↗
Source integration, analyzers, API, operations and security methods.
AI Estate, sign-in ↗
Authenticated customer systems and source-qualified inventory.
Research lens: ISAF v2 manuscript work informs the instruction-to-consequence and proof frontier methodology. Publication was pending at time of writing. CSM6 can help frame governance and operations, but neither research framework should be represented as an automatically executed HAIEC native control or certification.