Approval agent
Prove why an agent approved, held, or escalated a finance, procurement, compliance, or vendor action.
AI agents
Every agent action needs a reason a human can defend.
The biggest enterprise risk is not that an AI agent acts. It is that the agent acts inside a Fortune 500 workflow and the company cannot prove why the action cleared, what evidence mattered, what rule applied, what uncertainty remained, and where human authority stayed. Forge is the proof layer for that moment.
Enterprise agents
Fortune 500 workflows
Pre-action gates
Human authority
Why this leads
AI agents turn governance from a quarterly review into a per-action problem.
- Agents act across systems. Identity tells you who the agent is. Forge shows whether the specific action was justified.
- Enterprise buyers need proof before scale. Fortune 500 teams cannot roll agents through finance, legal, cyber, insurance, procurement, or operations on trust alone.
- Average evals are not enough. The one action being challenged needs its own proof trail: evidence, rule, uncertainty, and human boundary.
- Calibration matters over time. Outcome tags show whether the workflow is calibrated without product training on customer data or cross-customer learning.
Where Forge sits in an agent workflow.
| Proof | The agent or orchestrator reports at checkpoints. Forge builds a proof trail around what happened and why the supplied evidence supported the action. |
|---|---|
| Gate | Before a meaningful action, the agent asks Forge. Forge returns proceed, hold, escalate, or reject with the proof trail behind it. |
| Enforce | Inside a customer-approved protected boundary, a wrapped tool or API does not forward the action when Forge returns hold or reject. |
| Measure | The customer later tags outcomes. Forge compares prior confidence to results and shows whether that agent workflow is earning trust. |
First agent workflows for enterprise buyers.
Cyber response agent
Gate selected response actions so the team can show what evidence supported the action and what stayed uncertain.
Customer or claims agent
Preserve the policy, evidence, uncertainty, and human-review boundary behind pay, deny, bind, refund, or escalate.
Illustrative proof trail: a high-consequence agent action.
The following is a synthetic, representative example: a billing-support agent proposes a customer refund that sits above the automatic-approval ceiling while the reported duplicate charge is still unconfirmed. Before the refund is issued, the action is pointed at the Forge API against the customer's encoded refund-authorization policy. Names, amounts, and hashes are illustrative and do not describe any real customer, agent, or record.
decision_id: agt-2026-05-09-0004471
surface: support_agent_refund_authorization
agent: billing_support_agent_v3
policy_ref: refund_authorization_policy_v4 (hash sha256:2c7f10... )
disposition: ESCALATE
confidence: 0.68
data_reliability: 0.71 (dispute evidence partially unverified, see e3)
evidence_chain:
e1 refund_amount = "4,250.00 USD"
source: billing_system_invoice_INV-88213 | hash sha256:a19b4c...
e2 auto_approve_ceiling = "1,000.00 USD"
source: refund_authorization_policy_v4 | hash sha256:2c7f10...
e3 dispute_reason = "duplicate charge, customer-reported"
source: support_ticket_T-40912 | hash sha256:6d51e0...
note: no matching duplicate found in ledger yet (unverified)
e4 account_standing = "good, 3-year tenure"
source: crm_account_record | hash sha256:0f83aa...
extraction: normalized pre-decision, outside signed path
alternatives_considered:
a1 APPROVE rejected: amount exceeds auto_approve_ceiling (e1 vs e2)
a2 DENY not selected: account in good standing, claim plausible
a3 ESCALATE selected: over-ceiling amount plus unverified duplicate
uncertainty_held:
- reported duplicate charge not yet confirmed in ledger (e3)
- refund amount is 4.25x the auto-approve ceiling
human_review_boundary:
route_to: billing_supervisor_queue
reason: amount over ceiling AND duplicate charge unverified
recommended_next_action:
confirm duplicate in ledger, then re-run; or route to a billing
supervisor for a documented approval or denial with rationale
signature: Ed25519 (integrity check; verifies offline)
replay_key: rk_9a2e77b0d... (same input reproduces this record)
Read it the way a reviewer would. Identity tooling can confirm the agent was allowed to act; it cannot show whether this action was justified. The disposition here is not "the agent refunded the money." It is that the policy, applied to these exact inputs, holds the action for human review, and precisely why: the amount cleared the auto-approve ceiling and the reported duplicate charge was not yet confirmed in the ledger, so confidence was capped rather than quietly asserted. The action routed to a billing supervisor with the reason attached, and the signed proof trail replays offline so an auditor can re-derive the disposition without trusting the agent's own logs. Forge returns the disposition and the proof trail. The human keeps the decision.
Bring one agent action before the rollout gets broad.
Forge starts with one agent, one action menu, and synthetic, sanitized, or approved workflow evidence. The buyer sees the proof trail and calibration path before turning the agent loose across more work.