Wrong target
The approved operation reaches a different user, group, role, or permission.
Execution assurance for AI-assisted identity changes
Prove the access change that executed is the one a human approved.
Intent Accord independently reconciles approved intent with authoritative identity-system evidence, then preserves a tamper-evident record of the result.
Human authority · Independent evidence · Deterministic verification
THE EVIDENCE SPINEArchitecture
01INTENT
Recommended
AI-assisted proposal
02FROZEN
Approved
Exact action · authorized human
03CLAIM
Attempted
Executor’s receipt is a claim
Independent verification path
04SOURCE
Observed
Authoritative target-system audit evidence
05
Verified
Approved compared with observed · deterministic
What was approved?
What actually happened?
Did they match?
Can we prove it?
01 / The assurance gap
Approval is not
proof of execution.
A valid identity and an authorized decision do not guarantee the right outcome. An API success response is not independent evidence. Logging an action is not the same as verifying it.
Between recommendation, approval, execution attempt, and the system’s recorded outcome, details can diverge. Intent Accord’s architecture is designed to make that gap visible.
Partial execution
A workflow reports success while the recorded outcome reflects only part of the intended change.
Missing evidence
A receipt exists, but authoritative evidence is insufficient to establish what happened.
Out-of-band change
The recorded state may differ from the approved workflow. Attribution requires authoritative evidence.
02 / From intent to evidence
Five states. One traceable record.
Connected by evidence. Kept distinct by design.
01
Recommended
Input / responsible identity
Proposed access action from an AI-assisted workflow.
Identity: recommendation sourceEvidence produced
Captured recommendation
A proposal is preserved separately. It is not permission to execute.02
Approved
Input / responsible identity
The exact action reviewed by an authorized human.
Identity: human reviewerEvidence produced
Frozen decision object
Records reviewer identity, authority, decision, and the approved action.03
Attempted
Input / responsible identity
The approved operation passed to a constrained runner.
Identity: allowlisted executorEvidence produced
Execution receipt
A record of the attempt. The executor’s claim is not independent proof.04
Observed
Input / responsible identity
Authoritative target-system audit evidence, read independently.
Identity: separate verification identityEvidence produced
Reconstructed recorded action
Execution as independently observed, rather than inferred from a success response.05
Verified
Input / responsible identity
Approved fields compared with independently observed fields.
Identity: verification path; deterministic engineEvidence produced
Match, mismatch, or unverifiable
Field-level results. A language model does not decide whether the actions match.Preserve the whole chain. Decision objects, receipts, observations, and results are linked in a hash-chained, tamper-evident evidence record.
03 / The difference that matters
A successful request.
A different result.
The request was valid. The approver was authorized. The executor reported success. The authoritative system recorded a materially different result.
A conventional workflow might show “approved” or “successful.” Deterministic comparison exposes the field that changed.
Illustrative scenarioACTION COMPARISONGroup membership
Approved target
SG-FinanceDB-ReadersAttempted target
SG-FinanceDB-ReadersObserved target Authoritative audit evidence
SG-FinanceDB-AdminsCritical mismatch
target.group differs from approved intent.
Authorized intent differs from observed outcome
04 / Product architecture
Assurance, built into
the evidence.
Six architectural capabilities connect the decision to the recorded outcome. Each has a distinct role; none substitutes for independent verification.
Frozen approval intent
Preserve the exact action the reviewer authorized as the basis for comparison.
Reviewer authority verification
Record who approved, check their authority, and apply separation-of-duties logic.
Constrained execution identity
Use an allowlisted identity to attempt only the approved operation.
Independent authoritative observation
Read target-system audit evidence through a separate verification identity.
Deterministic field-level comparison
Compare approved and observed fields. Return match, mismatch, or unverifiable.
Tamper-evident evidence chain
Link decisions and evidence with hashes so changes to the record can be detected.
05 / Alongside your existing stack
Add assurance without replacing your control plane.
Intent Accord is designed as an assurance overlay for the gap between authorized intent and observed outcome. Your identity, governance, and workflow systems retain their roles.
Identity systemsIGA & PAM
ITSM & approval workflowsAI-agent platforms
Intent AccordApproved intent compared with observed outcome
SIEM & audit systems
Designed to complement your stack
06 / A shared evidence base
Different responsibilities.
The same need for proof.
Identity Security
See whether a high-risk access change matches the operation that was actually authorized.
AI Governance
Keep AI recommendations separate from human authority and recorded execution outcomes.
Internal Audit
Trace an approval to authoritative observations and a tamper-evident verification record.
Enterprise AI Platforms
Design AI-assisted operations around constrained execution and deterministic outcome checks.
07 / Where we are today
Built beyond
the slide deck.
Advanced prototype in active Microsoft Entra validation.
Intent Accord is not yet in production. Microsoft Entra is the first validation target; the broader use cases and stack categories describe the intended scope, rather than completed integrations or partnerships.
Help shape what comes nextImplemented
Schemas, storage, execution runner, independent verification engine, and reviewer panel.
Checked
Extensive automated test coverage across the complete decision-evidence architecture.
Demonstrated
Real identity sign-in, reviewer authority checking, separation of duties, and tamper-evident decision recording in a dedicated Microsoft Entra environment.
In progress
Final live system-of-record execution and independent verification, completing end-to-end validation.
Seeking feedback
Early design partners, adopters, and practitioners to help validate the assurance approach.
Build the next step with us
Help define the assurance standard for AI-assisted identity changes.
We’re seeking identity-security practitioners, AI-governance leaders, security architects, auditors, and regulated enterprises evaluating AI-assisted operations.
Request early access
Opens a draft in your email app. No form data is collected here.
08 / A few important distinctions
Clarity before
complexity.
What is Intent Accord?
Intent Accord is an execution-assurance layer for high-risk, AI-assisted enterprise identity and access changes. Its architecture connects recommendation, approval, execution, authoritative observation, and deterministic verification to establish whether the recorded action matches authorized intent.
How is it different from an approval workflow?
An approval workflow records a decision. Intent Accord preserves that exact approved action and compares it with independent target-system audit evidence. Approval, attempted execution, and verified outcome remain separate states.
Does Intent Accord replace Microsoft Entra, IGA, or PAM?
No. It is designed to complement identity systems, identity governance and administration, privileged access management, and approval workflows. Its focus is the connection between authorized intent and the action the authoritative system recorded.
Why is independent observation necessary?
An executor’s receipt or API success response describes what the execution component reports. A separate verification identity reads the authoritative system’s audit evidence to reconstruct what that system recorded. If the evidence is insufficient, the result is unverifiable, not an assumed match.
Does an AI model decide whether execution matched approval?
No. Core verification is deterministic. AI or language models may assist with recommendation interpretation or evidence explanation, but they do not determine whether approved and observed action fields match.
Can the evidence record be changed?
The evidence is tamper-evident. Decision objects, receipts, observations, and results are linked in a hash chain to make changes detectable. This does not prevent all alteration or deletion, or guarantee permanent storage.
Where can I see the product’s current status?
The validation section brings together implemented capabilities, demonstrated milestones, and the next live test.
View validation milestonesWhich use cases are supported first?
The first validated workflow is sensitive Microsoft Entra security-group membership. Privileged-role assignments and application-permission changes are planned extensions of the same assurance architecture, not currently validated integrations.
How can I participate as a design partner?
Use the early-access email link to describe your role, the identity-change workflow you’re evaluating, and what evidence you need. Please do not include credentials, tenant identifiers, or confidential infrastructure details.
Request early access