Skip to main content
AI Agent Security · Evidence-Bound Assurance

What can your AI do with the access you already gave it?

A customer message can become an instruction. If the same AI can search internal data and send customer replies, a fully legitimate tool chain can turn untrusted content into a disclosure nobody intended.

Security finds attacks. Governance defines approved use. IAM describes access. HAIEC connects those facts to the path an AI can actually take, the consequence at the end, and the evidence behind every conclusion.

Every permission can be valid. The AI outcome can still be wrong.

Applicable to AI applications, AI systems, AI agents, AI tools, model/API integrations, automated AI workflows, and consequential agentic systems.

Illustrative agentic-risk pattern
Not a customer scan

What separate controls see

  • Customer message
    Normal input
  • Support AI
    Approved application
  • Internal search
    Permitted capability
  • Customer reply
    Permitted capability

All four can be valid

  1. Customer A sends a support message
    The message text can carry an embedded instruction
  2. AI support agent processes it
    An approved application doing its expected job
  3. Internal search runs
    The agent is permitted to look up account data
  4. Customer B's confidential data enters the reply
    The path crosses from internal data to an outbound channel
  5. A normal customer reply is sent
    A permitted outbound action closes the loop
  6. Potential consequence
    Customer A receives Customer B's confidential data
    Potential impact: cross-customer disclosure
HAIEC assurance layer · evidence, not middleware
  • What influenced it?
  • What can it reach?
  • Whose access does it use?
  • What controls the path?
  • Is there another route?
  • What does the evidence prove?
EstablishedPartialUnknownNot assessed

Unknown is reported as unknown. It is never presented as a pass.

Real-World Patterns

This is not hypothetical.

Publicly disclosed incidents keep repeating the same shape: individually legitimate capabilities connecting into an unintended consequential path.

Public input → private data → public output

A malicious public issue influenced an AI agent that could read private repositories and create public pull requests. Individually valid capabilities formed a data-leak path.

Trusted tools can create an untrusted sequence.

Publicly disclosed pattern · Invariant Labs, May 2025

Email → internal context → external leak

A crafted email could influence an enterprise AI assistant and cause internal data to leave through an external channel, without the user intentionally sharing it.

The input itself can become an instruction source.

Publicly disclosed pattern · Microsoft Security Insider, 2025

Agent → production data → destructive action

An AI coding agent deleted app database data during development; the platform later strengthened development/production isolation.

Natural-language intent is not the same as enforced authority.

Publicly disclosed pattern · Replit, July 2025

These are publicly disclosed patterns, not HAIEC findings. HAIEC does not claim to have detected or prevented any named incident. The assurance question is whether a comparable influence, reach, authority, and consequence path exists in your system, and what the evidence establishes about it.

System Constellation

See the paths a checklist cannot show.

HAIEC expands the agent into the system around it: what can influence it, what it can reach, what controls the path, whether another route leads to the same effect, and what the evidence actually proves.

Influence

User input, knowledge, memory, tool output, peer agents, runtime configuration

Reach

Tools, APIs, data, identities, cloud, workers, external services

Control

Authentication, authorization, tenant scope, approval, validation

Consequence

Data change, money movement, access change, production change, external communication

Explore the product-backed sample System Constellation
Sample environment · illustrative data
Static Sample
Northstar Commerce Operations Copilot
AI-assisted refund processing
Request
User / application input
Policy
System instruction
AI Agent
Model call
Action
stripe.refunds.create
Policy
Authentication
Action
Canonical path
Consequence
Stripe refund
Potential consequence
Permission ≠ Delegation
Permission can be valid while delegation of the consequential choice remains unproven.
Evidence & Authority

What does the evidence actually prove?

No vulnerability does not mean no consequential capability. A perfectly valid tool, called through a valid API, using a valid service identity, can still produce an action the organization never intended the AI to choose.

Permission is not delegation. Security controls answer whether an identity is permitted to do something. They do not necessarily establish whether the AI was delegated the consequential choice it made.

Permission

An identity policy that allows an action. Establishes what is permitted, not what was authorized by a human decision.

Delegation

Whether a human or process with authority actually delegated the consequential choice to the AI. Distinct from permission. Not always established by available evidence.

HAIEC does not claim delegation violations are currently proven unless evidence establishes them. The distinction between permission and delegation is a structural insight, not an automatic finding.

1. Intention

What you intend the AI to do

2. Policy

What your policy allows

3. Credentials

What credential evidence establishes

4. Capability

What the application can technically do

5. Observed

What HAIEC observed where supported runtime sources are connected

These are evidence questions, not a causal proof chain. A gap between any two is a finding, not a safe state. Not every question currently has a native evidence producer.

Alternate paths

Expected path

Request → approval → action. The mediated route reviewers expect the AI to take.

Alternate path

A background worker, fallback handler, or direct tool path that reaches the same effect through a different route.

Finding one approval does not prove every route to the action is protected.

How HAIEC Works

From repository to decision.

A bounded lifecycle for evidence-bound assurance of consequential AI systems.

Define

Select the AI system and assurance question

Connect

Connect evidence sources: repo, APIs, and infrastructure

Collect Evidence

Source, identity, access, policy, capability

Assure

Deterministic evaluation within explicit scope

Verify

Decision Receipt with SHA-256 integrity

Monitor

Ongoing evidence from supported runtime sources

Monitor is bounded to supported evidence and runtime sources. Not every connected asset has a native evidence producer. Evaluated Scope is currently structured at the contract level; structured scope binding is under development.

Evidence & Framework Support

Mapped to standards. Not defined by them.

HAIEC maps evidence to recognized frameworks and regulations. This is evidence mapping, technical evaluation, readiness, and assurance support. Framework mapping is not the same as assurance. A green or source-established fact is not the same as safe.

NIST AI RMF
OWASP LLM
ISO 42001

HAIEC supplies evidence and analysis. The qualified firm, CPA, certification body, or assessor retains professional judgment and issues the applicable attestation, certification, or assessment outcome. Framework mapping does not equal assurance.

Evidence-Bound Assurance for Consequential AI

What can this AI actually cause?

One bounded system. One primary assurance question. Explicit evidence boundary. Decision-grade technical and executive output.