iVALTAgentFlow

Every protected action waits for a proven human

Your agents keep moving until they reach an action enterprise policy protects. AgentFlow pauses the run, resolves the required human, binds five identity factors to the decision, and returns a signed proof.

How it works

One RPC call inserts the checkpoint. iVALT TrustLoop carries the verification.

authority-loop.ts
Authority requestREQ-4815 · Send records · certified mail
Resolve authority policyPerson, role, or team
Approver decides in TrustLoopFive factors bound to the decision
Sign + return proofSigned proof
Revise + resubmitFeedback to agent
Append audit chainAudit chain
request.submittedRequest 4,815Waiting for the next request

The approver’s endpoint

iVALT TrustLoop, on iOS and Android

The human half of the checkpoint, made on a phone.

See the mobile app

iVALT TrustLoop is the approver's endpoint. The home, the queue, and the five-factor verification live in one place, bound to the decision rather than to a session. The app holds no partner credentials.

The homeWhat is waiting on you, before anything else.
The queueRisk, confidence, and wait time before anyone opens a request.
The verificationFive factors, evaluated against this decision inside a visible window.

Get TrustLoop

iOS and Android, for enrolled approvers. The app holds no partner credentials; every decision it carries comes back to AgentFlow.

Enrollment is managed by your identity administrator.

Every protected action takes the same path. The agent does the work, a verified human makes the call, and a signed proof travels back with the result.

Jordan Reyestechnuff / correspondence agent

Request the claimant records from Meridian Mutual and send them by certified mail.

StartingTime0.0s0 tokens

    Seven steps, in the same order, for every request. The agent system and the mobile app never talk to each other; both talk to AgentFlow, which keeps the security boundary in one place.

    The review exists before the outcome

    Your agentic system reaches a consequential action and posts an authority request: action summary, risk, what would change, checks already run, reasoning, and evidence references.

    input · request_human_authority(…)

    Four parts of a protected decision. Hover a card to see it work; open one to try the control.

    Proposal, changes, checks, reasoning, evidence, and timeline read as one continuous document.

    Five identity factors, captured on the device and bound to the exact decision.

    Who can decide, what must be true, and how long a request stays open, set by administrators.

    Outcome, reason, verified decider, and identity assertion, signed as one record.

    • 5

      Identity factors per decision

      Bound to the decision, not the session

      Biometric, device, geofence, time window, app context

    • 60 s

      Verification window

      A countdown the approver can see

      A silent expiry on a high-stakes approval is a failure we surface, not hide

    • 3

      Outcomes a reviewer can send

      Approve, reject, or request changes

      A binary gate cannot express “right, but not ready”

    • ~5 yr

      Audit retention

      Append-only chain, payload stays with you

      Sized for the question a regulator actually asks

    Decisions are not traffic jams with better tools. What matters is who decided, whether the proof travels with the action, and that the record cannot be quietly rewritten.

    authority proof · PRF-4815
    decision
    approvedpass
    approver
    Jordan Reyes · verifiedpass
    factors
    5 / 5 bound to REQ-4815pass
    bound_to
    req:4815 · rev 2 · sha256:9f2c…idle
    signed
    ed25519 · TrustLoopidle
    retention
    append-only · ~5 yridle

    The append-only audit chain

    Six events, one spine. When someone asks why a claim was sent, the answer is a record, not a memory.

    1. req_4815declared
    2. req_4815policy resolved
    3. req_4815proposal frozen
    4. req_4815verified human
    5. req_4815decision recorded
    6. req_4815proof returned

    Manual escalation, session-scoped prompts, or no checkpoint at all. Each leaves a different gap the audit cannot close.

    Feature
    iVALT AgentFlowAuthority control plane
    Manual escalationSlack, tickets, war rooms
    Session-scoped authSSO and step-up prompts
    No checkpointDelegated authority runs on
    Who decides
    A required human, by policyResolved from the request, not hardcoded
    Included
    PartialWhoever answers
    Not included
    Not included
    Verified at the moment of deciding
    Included
    Not included
    PartialVerified at sign-in
    Not included
    Bound to the exact decision
    Included
    Not included
    Not included
    Not included
    What comes back
    A signed authority proof
    Included
    Not included
    Not included
    Not included
    Approve, reject, or request changesA binary gate cannot express “right, but not ready”
    Included
    PartialUnstructured
    Not included
    Not included
    Append-only audit chain
    Included
    PartialScattered threads
    PartialSession logs
    Not included
    Failed checks return to pending
    Included
    Not included
    Not included
    Not included
    What it costs you
    Policy as configuration
    Included
    Not included
    PartialAuth rules only
    Not included
    Payload stays with youContent hash and a display-safe summary stand in for it
    Included
    Not included
    Included
    Included
    No bypass when verification is down
    Included
    PartialDepends on the channel
    Not included
    Not included
    IncludedPartialNot included

    Showing all rows

    If verification only happens at sign-in, the record proves a session approved an action, not that a specific verified person did, from an authorized device, inside an authorized location and time window.

    Biometric

    The right human is present.

    Device ID

    A registered, bound handset.

    Geofence

    An authorized location.

    Time window

    Within authorized hours.

    App context

    A genuine request, not a replay.

    Without factor-level detail, five distinct causes collapse into one generic “verification failed.” On a high-value approval that is a poor and potentially costly experience.

    Failing factorWhat the approver should do
    BiometricRetry
    Device not registeredContact your identity administrator
    Outside geofenceMove to an authorized location, or hand off to a delegate
    Outside time windowWait, or hand off to a delegate
    Context or app mismatchBlocked. A possible replay raises a security event.

    One call pauses your agent at the moment enterprise policy says it must. Framed around authority rather than an approval screen, the same checkpoint drops into any agent framework: as an RPC call today.

    The interface is deliberately narrow. Your system owns the conversation and the workflow; AgentFlow receives only what it needs to resolve authority, present a safe summary, and bind the decision.

    agent →

    Authority session

    • Protected decision or conversation ID
    • Required person, role or authority
    • Action summary plus risk and policy result
    • Hash or reference to full context
    • Evidence and reasoning references
    • Assurance requirements and expiry
    • Callback or execution endpoint

    ← proof

    Proof result

    • Verified human, the authority subject
    • Trusted device and assurance result
    • Approve, reject, or request changes
    • Response bound to exact proposal and version
    • Revision lineage and conversation state
    • Final decision hash and timestamp
    • Cryptographic proof, proof ID, audit reference
    submit-request.shshell
    # One call pauses the agent at the policy checkpoint.
curl -X POST https://agentflow.example/api/v1/partner/submitRequest \
  -H "x-partner-key: <your partner key>" \
  -H "content-type: application/json" \
  -d '{
    "json": {
      "externalRequestId": "REQ-4815",
      "idempotencyKey": "req-4815-v1",
      "workflowKey": "insurance.on_behalf_of_mail",
      "conversationId": "conv_9f2c7a",
      "title": "On behalf of mail · records request",
      "actionType": "send_records_request",
      "actionSummary": "Request records from Meridian Mutual.",
      "requiredAuthority": { "role": "licensed_adjuster" },
      "contentHash": "sha256:9f2c…",
      "evidenceRefs": ["evidence://claim-4815/summary"],
      "displaySnapshot": { "delivery": "Standard → Certified mail" },
      "riskLevel": "high",
      "assurance": { "minFactors": 2, "allowDelegate": true },
      "expiresAt": "2026-08-29T10:12:00Z",
      "callbackUrl": "https://your-system.example/agentflow/callback"
    }
  }'

    Idempotent by design

    Every submission carries an idempotency key, so a retry after a timeout cannot create a second protected decision.

    Expiry is yours to set

    A request stays open for as long as your workflow says it should. Past that it is stale, and the approver sees it as such.

    Blocked, not bypassed

    If verification is unavailable the platform enters read-only review. Decisions are blocked rather than let through.

    None of these change how your agents decide what to propose, only how they hand a proposal off for review.

    Submit an action for approval

    Title, summary, what would change, confidence, risk, check results, reasoning and evidence references. This is the only new call your agent makes.

    Receive the decision

    Outcome, who decided, when, and any note or structured reason, read back once the decision is recorded.

    Handle “request changes”

    Revise against the feedback and resubmit. The revision carries its own lineage back to the original protected decision.

    Check status or withdraw

    At any point before a decision is made, read where a request stands or pull it back if it is no longer relevant.

    Storing insured names, dates of birth, claim numbers and authorization documents for five years would expand everyone’s compliance scope. The default avoids it.

    payload
    stays in your systems
    content hash
    what was decided about
    display summary
    what the approver saw
    evidence refs
    pointers, not copies
    decision
    the outcome and its reason
    proof record
    verifier, factors, signature

    You retain regulated content

    AgentFlow stores a content hash, a display-safe summary, evidence references, decision data and the proof record. That is enough to prove a specific document was approved by a specific verified person, without holding the document.

    Full storage is a choice, not a default

    If a deployment needs complete retention, it should be a deliberate, priced position, not an architectural accident.

    Everything you need to know before install your first component.

    • Only what the approver needs to read. The regulated document stays in your systems; AgentFlow holds a content hash, a display-safe summary, and pointers to your evidence.

    The clickIntegrate the checkpointOne RPC call pauses your agent where enterprise policy requires a human. The contract is narrow; the proof is signed.Read the integrationThe conversationTalk to the teamDeployment, authority policy, proof retention — bring the workflow you would protect.Start the conversation

    Works with any agent framework