Approval agent
Prove why an agent approved, held, or escalated a finance, procurement, compliance, or vendor action.
AI agents
Check the action before your AI takes it.
An AI agent may draft a reply, propose a payment or change a system. Forge checks selected actions against the rules and evidence you provide, then records the result and any required review. Your connected system enforces the result. It needs a tested control point the agent cannot bypass.
Enterprise agents
Fortune 500 workflows
Pre-action review
Human authority
Why this leads
Checks belong where the action happens.
- Agents act across systems. Identity tells you who the agent is. Forge records what disposition the supplied evidence and encoded policy produced for the selected action.
- 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 is consented. Only authorized customer outcomes with explicit retention opt-in create tenant-local calibration state. Without retention opt-in, no calibration row is written.
Where Forge sits in an agent workflow.
| Proof | The agent or orchestrator reports at checkpoints, and Forge records the supplied evidence, policy result, uncertainty, and human boundary. |
|---|---|
| Pre-action | Before a selected action, Forge returns a menu-bound disposition and proof trail. Forge does not execute the action. |
| Execution control | The customer's qualified, validated, exclusive protected boundary applies the customer's exact policy and controls forwarding. Forge itself does not authorize, forward, or execute the downstream action. |
| Measure | The customer later tags outcomes. Forge compares prior confidence to results and shows whether that agent workflow is earning trust. |
Examples for your business.
Cyber response agent
Review selected response actions before execution, with the customer-owned protected boundary applying the final execution policy.
Customer or claims agent
Preserve the policy, evidence, uncertainty, and human-review boundary behind pay, deny, bind, refund, or escalate.
Example: a refund needs a supervisor.
A billing agent proposes a refund above its approval limit. The customer reports a duplicate charge, but the ledger has not confirmed it. The example below shows the evidence and rule that would require human review. It is synthetic: this page makes no API call, creates no signature and issues no refund.
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
complete_record_signature: not generated by this walkthrough
trust_anchor: full expected key ID must be provisioned separately
replay_key: rk_9a2e77b0d... (illustrative; replay compares action + replay key)
Read it the way a reviewer would. Identity tooling can confirm the agent was allowed to act; it cannot show what disposition the supplied evidence and encoded policy produced. 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 exceeded the auto-approve ceiling and the reported duplicate charge was not yet confirmed in the ledger, so confidence was capped rather than quietly asserted. In a managed integration, that disposition could be routed to a billing supervisor with the reason attached. A real reviewer would verify the complete-record signature against an independently provisioned full key ID, then replay the governed action and replay key separately. This synthetic page does none of those operations. The human keeps the decision.
Bring one agent action before the rollout gets broad.
Forge is live and tested, at design-partner stage. It starts with one agent, one action menu, and synthetic, sanitized, or approved workflow evidence. The buyer can inspect the proof shape and calibration path before any protected action is in scope.