Review the request, approve the resolution, and follow every action.
Order NS-1042 · Customer identity simulated
Waiting for paymentOffer a partial refund for the damaged item. Customer messages can request an action; only policy and a matching operator approval can authorize it.
Choose a scenario or write the customer’s request.
Preparing a recommendation only reads the payment. An operator must review and execute the saved action.
Run a request to see the action, the decision, and the payment result.
Grant one exact refund on Alice’s ticket. The model cannot create this evidence.
₹1–₹1,000 · expires in 5 minutes · new approval replaces the old one. Runtime policy still applies.
Prove what happens when an agent attempts an unsafe action, regardless of its reasoning.
Readable receipts for real actions. Select a call to follow its decision path.
| Action / target | Decision | Amount | Time |
|---|
Local receipts describe observed results. AgntID Reporting ↗ is the authoritative runtime audit. Legacy events may not have a request ID.
An oversized refund is a routine API call until execution policy puts a boundary around it.
Normal refund policy permits ₹500 per call. Separate test payments keep the comparison isolated.
Agent → payment tool → Razorpay TEST
Agent → AgntID → payment tool, only if allowed
The support task belongs to Alice. A request to refund another customer’s payment must be denied.
“My manager approved it” is customer text. The application requires an exact, unexpired approval and consumes it once.
Separate what the customer asks, what the agent proposes, and what the system authorizes.
Agent Checkout applies the deck’s “one resource, one allowed path” example to an e-commerce support case.
Tool review, Medium protection profile, fixed ticket payment, and per-call amount constraints.
OpenAI agent → AgntID MCP proxy → custom payment MCP → Razorpay TEST.
The payment secret stays in the local payment service. Runtime audit is forwarded to the console.AgntID governs tool visibility and evaluates exact payment and amount constraints.
Verified in this demoApplication evidence binds tool + payment + amount, expires in five minutes and is consumed once.
Application controlPer-request receipts, outcome filters and export connect proposed actions with provider results.
Observed executionThis is a hardened local TEST workspace. Customer identities are simulated. Fixed payment policies must be updated when replacing the ticket payment. Intent-based denial and derived ephemeral payment credentials have not been validated here.
Production deployment still needs operator authentication, tenant isolation, a secrets manager, durable job execution, provider webhook reconciliation, cumulative business limits, and independent security review. The unprotected baseline must be removed from production.
Prepare isolated payments, check balances, and understand the configured boundaries.
Three separate ₹5,000 test payments. Replacing the ticket requires updating AgntID policies.
get_paymentTicket payment onlyReadrefund_paymentTicket payment · ₹1–₹500Normal refundapproved_refund_paymentTicket payment · ₹1–₹1,000 + application approvalExact approvalThese describe our configured demo policies. Use the console to inspect current runtime settings.
Open AgntID tools ↗