Research and control rationale

Why agents need approval at the moment of action.

A model can choose a tool, but it should not be the final authority for an irreversible operation. GoodRoom.verify creates a narrow, cryptographically verifiable human decision between intent and execution.

What industry guidance says

These sources do not endorse GoodRoom.verify, and using the product does not establish compliance. They independently describe the risk patterns and control principles the product is designed to address.

OWASP GenAI Security Project

LLM06:2025 Excessive Agency

Identifies excessive functionality, permissions, and autonomy as root causes. Recommended mitigations include human approval for high-impact actions and authorization in downstream systems.

Read primary source

Model Context Protocol

Security Best Practices

Calls for explicit consent, token audience validation, scope minimization, secure random identifiers, and controls that preserve accountability across MCP trust boundaries.

Read primary source

NIST

AI RMF: Generative AI Profile

Provides a voluntary, cross-sector profile for incorporating trustworthiness into the design, development, use, and evaluation of generative AI systems.

Read primary source

European Commission

AI Act risk-based framework

Describes risk assessment, activity logging, documentation, human oversight, robustness, cybersecurity, and accuracy as obligations for covered high-risk AI systems.

Read primary source

From risk to control

Unexpected or manipulated model output

A separate person reviews the action immediately before execution.

Approval applied to a different action

The signed proof binds the SHA-256 action digest and tool audience.

Standing authorization reused later

Challenges expire after 120 seconds; proofs expire after 30 seconds and carry a unique ID.

Opaque agent activity

D1 stores the decision, digest, audience, risk, account, credential reference, and timestamp.

Prompts copied into a control plane

The service does not persist prompts, tool arguments, source code, or conversation context.

Approval is one layer. Least privilege, narrow tools, deterministic validation, sandboxing, rate limits, and downstream authorization remain necessary. A human checkpoint should not compensate for an overpowered tool.

Does this cover financial transactions?

Yes, at the approval layer. The current proof is action-agnostic, so a payment wrapper can require a passkey-backed proof before submitting a transaction. GoodRoom.verify is not itself a payment processor or a complete financial-control system.

Covered by the product now

Require Touch ID or another passkey before a payment tool runs
Bind approval to a canonical digest containing amount, currency, beneficiary, and payment reference
Bind the proof to a payment-specific audience such as tool:payment.send
Expire authorization quickly and deliver the proof only once
Persist a minimal decision audit record without storing account details in GoodRoom

Must be supplied by the payment system

Connecting to a bank, card network, wallet, Stripe, or other payment provider
Fraud, sanctions, AML, beneficiary, balance, or account-ownership checks
Regulatory authentication or compliance obligations for a specific jurisdiction
Amount thresholds, multi-person approval, separation of duties, or team policy
Payment idempotency, settlement, reconciliation, refunds, and receipt storage

Recommended payment binding

canonical_action = {
  operation: "send_payment",
  amount_minor: 250000,
  currency: "INR",
  beneficiary_id: "verified-beneficiary-id",
  payment_reference: "invoice-2026-1042"
}
action_hash = sha256(canonical_json(canonical_action))
audience = "tool:payment.send"

The payment wrapper must recompute this digest, verify the proof, enforce its own policy, reserve the proof ID against replay, and only then call the provider.

Start with one consequential tool

Choose an operation whose impact is clear, define a canonical action digest, and make proof verification mandatory in the wrapper.

Read the guide