3S TrustGate — USER Authorization for Agentic Commerce

When AI shops, users stay in control. 3S TrustGate stops actions if terms change, requires fresh authorization & documents the simulated outcome. Accessible, bilingual, Simple, Smart & Secure.

Comment

3S TrustGate — A Recommendation Is Not Permission

The Missing USER Authorization Layer for Agentic Commerce

Simple • Smart • Secure — Human-led, AI-assisted, USER-authorized.

Inspiration

**AI agents are moving from answering questions to preparing consequential actions. In agentic commerce, a user might approve a particular product, seller, total, and delivery date—then discover that one or more terms changed before execution. A system should not treat yesterday's approval as permission for today's different action. 3S TrustGate addresses that consent gap: AI recommends. Policy decides. USER authorizes.

AI agents are becoming increasingly capable of making recommendations and preparing transactions. But who ensures that the USER—not the AI—authorizes the exact action that ultimately takes place?**

An AI shopping agent may discover a product, compare offers and recommend a purchase. A person may approve a particular product, merchant, total and delivery date. But what happens if those terms change before execution?

A recommendation is not permission. And yesterday's approval is not authorization for today's different transaction.

3S TrustGate addresses this missing USER Authorization Layer: AI recommends. Deterministic policy enforces the boundaries. The USER authorizes.

We believe trustworthy agentic commerce requires more than intelligent recommendations. It requires understandable, transaction-specific human consent, especially when AI systems begin taking consequential actions on people's behalf.

The project is founder-led within Surprise Futures & Network LLC, developed through collaboration with multiple independent AI systems and informed by lessons from SF/LA Tech Week.

As a multilingual immigrant founder living with a disability, I care especially about clarity, accessibility, reduced interaction friction and meaningful choice. English/Spanish support and alternative authorization methods are not decorative extras: they are part of the product philosophy.

Our vision is an intelligent future that becomes more capable without making people less empowered.

What it does

The solution: A USER Authorization Layer

3S TrustGate is a working browser-based simulated Alexa+ agentic-commerce experience, using entirely synthetic headphone offers and merchants.

It demonstrates an authorization boundary between AI-assisted recommendations and simulated transaction execution.

The journey follows:

ASK → DISCOVER → COMPARE → VERIFY → EXPLAIN → PAUSE → AUTHORIZE → ACT → TRUST RECEIPT

The user reviews a Decision Card containing the proposed product, synthetic seller, price, quantity, delivery and other material transaction details.

Approval requires deliberate human action through HOLD TO AUTHORIZE or an accessible two-step alternative. Authorization is tied to the material transaction snapshot, expires after a bounded interval and cannot silently cover a materially different purchase.

Our signature demonstration: $119 becomes $128

The original synthetic offer totals $119, with delivery on October 23.

After initial authorization, a scripted update changes the total to $128 and postpones delivery to October 26.

Rather than quietly proceeding under stale consent, the deterministic Trust Kernel:

  1. DETECTS the material changes.
  2. STOPS the simulated action from proceeding under outdated authorization.
  3. EXPLAINS what changed and why fresh consent is required.
  4. INVALIDATES the previous authorization—even if the original values are restored within the same running session.
  5. REQUESTS a deliberate new human decision.
  6. ALLOWS simulated completion only after the updated transaction is explicitly authorized.
  7. GENERATES an informational Trust Receipt showing the authorized transaction and simulated outcome.

The most important successful action may be the one the AI is not allowed to take.

Key features, differentiators and benefits

USER authorization, not agent self-permission. An AI's recommendation or explanation cannot independently authorize an action.

Precise, bounded consent. Approval applies to specific material transaction terms rather than granting indefinite or blanket permission.

Deterministic enforcement. Security-relevant decisions are separated from model-generated recommendations and explanatory language.

Readable Decision Cards. Users can understand what they are being asked to authorize.

Deliberate approval alternatives. HOLD TO AUTHORIZE, a two-step alternative and implemented keyboard interactions support different user needs.

English and Spanish support. Core authorization and explanation flows are bilingual.

Stale-consent refusal. Material changes trigger a STOP rather than an assumption of continuing permission.

Trust Receipts. Informational records make the simulated authorization outcome easier to understand and review.

Lightweight, adaptable architecture. The underlying consent pattern could potentially extend beyond shopping to subscriptions, bookings and other delegated decisions.

Why it matters

For people: Greater clarity, agency, accessibility and protection against silently changed terms.

For developers: A practical separation between AI recommendation, trusted transaction facts, deterministic policy and permission to execute.

For future agentic-commerce ecosystems: A reusable design direction for accountable delegation and meaningful human oversight.

Try the project

WORKING INTERACTIVE DEMO: https://sfn-trustgate-demo.netlify.app

PUBLIC VIDEO DEMONSTRATION — 2:55: https://youtu.be/17DxYvv38YA

The video combines project explanation and illustrative BEFORE/AFTER imagery. The live browser prototype provides the interactive implementation for judging.

How we built it

The core is a lightweight HTML, CSS and JavaScript browser application, with a separate deterministic Trust Kernel.

The implementation includes:

  • Transaction-fact validation against a strict allowlist, with normalization of material terms.
  • Authorization tied to a SHA-256 digest of the transaction snapshot using the browser's Web Crypto API.
  • Execution-time comparison to detect material changes after approval.
  • Explicit invalidation of stale or expired authorization.
  • In-memory safeguards against repeated or concurrent execution attempts within the prototype's defined scope.
  • Stable idempotency-key generation for simulated retries.
  • Deliberate HOLD and accessible two-step authorization interactions.
  • English/Spanish decision explanations.
  • Informational simulated Trust Receipts.
  • Automated Node.js tests covering changed terms, invalid data, consent expiration, replay/concurrency attempts, action failures and receipt-generation edge cases.

A separate ID-only recommendation adapter is implemented in source, with a Netlify serverless proxy design. The model-facing recommendation layer is restricted to selecting a catalog product identifier and providing non-authoritative explanation. It cannot set authoritative prices, merchant facts, permission or execution terms.

The submitted demonstration uses OFFLINE SCRIPTED recommendations unless a genuine live-provider response is separately configured and verified. We do not claim that the recorded demonstration represents a live AI-provider call.

GitHub supports source control, reviews and test workflows. Netlify hosts the publicly accessible browser demonstration.

Development was human-led and supported by a collaborative team of advanced AI systems offering independent analysis, architecture suggestions, adversarial critiques, testing perspectives and creative contributions.

The aim was not simply to generate code with AI, but to use independent AI perspectives to challenge assumptions and improve the result while preserving human decision-making.

Challenges we ran into

1. Making authorization safe without making it burdensome

The central engineering challenge was building a meaningful consent boundary without overwhelming users with technical detail.

Independent AI-assisted adversarial reviews helped expose edge cases involving material-term changes, authorization reuse, concurrent execution, failed actions and unsupported receipt claims.

We refined the Trust Kernel, added regression tests and documented the boundaries of what our browser prototype can—and cannot—guarantee.

2. Real founder testing exposed a BEFORE → AFTER usability problem

Our earliest functioning interface correctly blocked the changed transaction, but presented a practical difficulty:

The warning explaining the refusal was separated from the Decision Card where the founder needed to provide fresh authorization.

As a result, the founder had to scroll repeatedly, while technical explanations and earlier warning states competed with the next safe action.

BEFORE: Correct deterministic protection, but a confusing path to renewed authorization.

AFTER: We added a visible “Review updated terms & re-authorize” navigation action directly inside the warning.

This guides the person toward the existing Decision Card without granting approval or bypassing the Trust Kernel.

The implemented improvement does not claim to eliminate every usability issue. It is a concrete step toward a simpler, more accessible interface.

Our video illustrates this BEFORE/AFTER journey, while the live browser demo lets judges inspect the implemented authorization behavior.

3. Developer-tool and submission friction

We documented several firsthand obstacles encountered while building and submitting the project:

  • Devpost: Gallery captions and a Try It Out link appeared missing after navigation, requiring manual re-entry.
  • Netlify onboarding: A generated deployment route resulted in “Page not found,” requiring an alternative setup path.
  • Public deployment access: The initially private demo blocked anonymous visitors; we corrected visibility and verified access.
  • GitHub: Private-repository judging invitations required exact usernames and manual access checks.
  • TrustGate UX: Finding fresh authorization after refusal required unnecessary scrolling until we added clearer navigation.

For each issue, we documented the task, expected and observed behavior, severity, workaround and actionable improvement suggestions.

Developer Friction Log: https://github.com/surprisefutures/3s-trustgate/blob/feature/gemini-id-only-adapter/docs/AMAZON_SUBMISSION_FRICTION_LOG_OCT21.md

Founder UX BEFORE/AFTER Case Study: https://github.com/surprisefutures/3s-trustgate/blob/feature/gemini-id-only-adapter/docs/FOUNDER_UX_FRICTION_BEFORE_AFTER_OCT21.md

These records are provided for consideration under the hackathon's optional developer-friction feedback criteria. The repository is private and accessible to authorized reviewers.

Accomplishments that we're proud of

1. Turning an important principle into executable behavior

Our signature achievement is demonstrating that human authorization belongs to an exact transaction—not indefinitely to an AI agent.

When a synthetic purchase changes from $119 to $128 and delivery is delayed, TrustGate identifies the material differences, invalidates the previous consent and refuses to act until the user deliberately approves the changed terms.

This is not merely a policy statement or presentation concept. The core authorization and refusal flow is implemented in a working prototype.

2. Building a lightweight, testable Trust Kernel

We separated AI-facing recommendation logic from deterministic authorization enforcement.

We implemented transaction-snapshot binding, expiration, material-drift refusal and session-bounded safeguards, with automated tests and documented limitations.

We are especially proud that the system is designed to refuse an unauthorized action, even when the proposed purchase otherwise appears reasonable.

3. Designing for inclusion from the beginning

English/Spanish support, keyboard interactions, deliberate HOLD approval and an accessible two-step alternative reflect our commitment to human-centered design.

As a multilingual founder with a disability, I consider accessibility a core requirement of trustworthy technology, not a feature to add at the end.

4. Learning from real BEFORE/AFTER founder experience

We identified genuine friction in our own prototype and implemented a clearer route from refusal to reauthorization.

That improvement required us to confront a difficult truth: correct enforcement and usable human control must exist together.

5. Making independent multi-AI collaboration productive

We brought together different AI perspectives for research, architectural reasoning, adversarial critique, development assistance, testing and creative communication.

Rather than treating AI as a single interchangeable tool, we used disagreement and independent review to strengthen decisions while keeping the founder responsible for the direction and final acceptance.

6. Delivering a working, accessible demonstration

We developed and deployed an interactive browser prototype, created a public video presentation, tested access across ordinary and private browsing, and documented the code, limitations and developer experiences for judging.

7. Establishing a potentially reusable design pattern

Although this demonstration focuses on agentic shopping, its underlying architecture explores a broader idea:

Consequential AI-assisted actions should be explicit, scoped, revocable and reviewable.

We believe that protecting human agency and creating elegant, efficient AI experiences can be complementary goals—not competing ones.

The 3S philosophy, demonstrated

SIMPLE: Understandable decisions, fewer confusing steps and visible next actions.

SMART: AI-assisted recommendations kept separate from deterministic policy and human permission.

SECURE: Authorization bound to exact material terms, with changed or stale consent refused within defined prototype boundaries.

We are proud to have created a functioning demonstration of this philosophy—not merely a slogan.

What we learned

A recommendation is not permission, and permission must not silently survive a material change.

We learned that one of the most valuable moments in an agentic workflow is when the system correctly refuses to proceed.

We also learned that deterministic policies should remain separate from AI-generated explanations and suggestions. Intelligent assistance should improve decisions, not give the agent authority to rewrite the facts being authorized.

Real founder testing taught us that technical correctness does not automatically create a good user experience. If people cannot easily understand why an action stopped or how to proceed safely, the design still needs work.

Independent AI reviews strengthened our implementation by exposing assumptions about replay handling, concurrent actions, failure states and receipts.

The project also reinforced the importance of honest claims:

  • Our Trust Receipts are informational simulation records, not cryptographically signed proof of payment.
  • Current replay protections are limited to the prototype's runtime rather than durable production controls.
  • Synthetic merchants are not independently verified retailers.
  • A simulated Alexa+ experience is not a production Alexa+ integration.

Perhaps our most important development lesson was:

Build less. Prove more. Preserve USER agency at every consequential step.

What's next for 3S TrustGate — From Agentic Commerce to the Autonomous Economy

3S TrustGate begins with a practical shopping simulation, but its underlying authorization pattern may apply to other delegated decisions in an increasingly autonomous economy.

Potential next steps include:

  • Verified live AI recommendation integration with constrained authority.
  • Trusted merchant and provider-backed transaction facts.
  • Durable server-side authorization and replay protection.
  • Stronger user identity and authentication mechanisms.
  • Independently verifiable transaction and receipt records.
  • Further keyboard, screen-reader, zoom and multilingual accessibility testing.
  • A simpler, consolidated consent interface.
  • Carefully scoped integrations for commerce, subscriptions, bookings and other consequential actions.

We envision a reusable USER Authorization Layer that could help AI systems become more capable while remaining accountable to the people they serve.

A personal note to the judges

Dear Amazon Developer Hackathon Judges,

We recognize how many innovative projects you may be reviewing, and we sincerely appreciate the time, attention and care you bring to evaluating each submission.

Thank you to Amazon Developer and Devpost for creating an opportunity for experimentation, learning, constructive developer feedback and new ideas.

For me, as a multilingual immigrant founder living with a disability and working alongside an independent team of AI collaborators, this project represents more than a technical demonstration. It represents the possibility of building technology that respects individual choice, reduces barriers and makes advanced AI useful without making people powerless.

We would be especially grateful if you explored the working browser demonstration, witnessed the $119-to-$128 authorization refusal, and reviewed our documented developer-friction and BEFORE/AFTER learning.

Our hope is that 3S TrustGate contributes a small but meaningful step toward more human-centered agentic systems.

Thank you again for your consideration and for supporting innovation that can help shape a better future.

With appreciation and warm regards,

Darina Joy
Founder & Producer
Surprise Futures & Network LLC
3S — Simple, Smart & Secure

A RECOMMENDATION IS NOT PERMISSION.

AI recommends. Policy enforces. The HUMAN decides.

Built With

Share this project:

Updates

Submission history