Trust Agent: AI-powered Compliance Intelligence for AWS Marketplace
Large software enterprises manage 280+ third-party software vendors. Every new vendor has to clear a compliance or security review before procurement can close the deal and that review is where software deals stall.
I led UX design for Trust Agent, an AI-powered compliance experience in AWS Marketplace that reduces an 8–10 week manual vendor risk assessment into a self-serve, minutes-long, conversational flow.
To comply with confidentiality agreements, some product details and metrics are approximated or omitted in this case study.
The context
How enterprise software procurement works
Large enterprises manage 280+ third-party software vendors. Buying a new software product involves multiple teams working in parallel:
Procurement manages contracts, negotiates pricing, and triggers the vendor assessment.
IT implements security policies — SSO, access controls, deployment architecture.
CISO/CRO (Chief Information Security Officer) sets the risk mandate: which vendors are acceptable and under what conditions.
TPRM (Third-Party Risk Management) conducts the vendor risk assessment that gates whether procurement can sign. This runs parallel to deal negotiation, often as part of the CISO/CRO organization.
Small and Medium Business typically manage 50 – 60 vendors; large enterprises typically manage 180 – 300+ vendors. Procurement cannot close a deal until TPRM completes the risk assessment.
The pain: a broken, manual process
For each new vendor, TPRM analysts must:
Request compliance documentations and penetration test reports under NDA
Review returned evidence against the organization's control framework (SIG, CAIQ, custom questionnaires)
Determine whether the vendor meets the acceptable risk standard
This takes 8–10 weeks per vendor and consumes 5,000+ analyst hours per year across the portfolio. Over a third of SaaS deals are delayed by security review or lost entirely.
Security teams routinely send standardized questionnaires to vendors, then wait days or weeks for responses. The back-and-forth is slow, inconsistent, and creates bottlenecks in the procurement cycle.
Why the previous solution failed
AWS Marketplace launched Vendor Insights (VI) in 2022 as a builder model, asking ISVs (Individual software vendor) to fill in a 125-question self-assessment, manually upload certifications, and maintain profiles directly on AWS Marketplace. After 3 years, the results told a clear story:
Metric result
About 200 ISVs onboarded (3% vendor penetration, 1% product coverage)
50 report downloads (all of 2025)
Below 10% NDA form completion rate
200 customers requested to NDA-gated reports , below 10% were approved
About 50,000 compliance badge views
The takeaway: 50,000 compliance badge views proved that customer demand for compliance signals exists but the builder model failed because ISVs already maintain compliance evidence through their own providers (Vanta, Drata or self-hosted). Asking them to maintain a separate AWS profile created duplicate work with no incremental value, and the model scaled linearly.
My strategic insight: Trust Agent needed to move from a builder model to an aggregator model, one that scales with the compliance provider ecosystem and meets customers where they already are.
Research & discovery
Customer interviews
I led early research with SMB and Enterprise customers including Robinhood, MongoDB, JFrog, Dynatrace, and AWS Security to understand their current pain points, validate our initial assumption and how we could optimize the compliance journey for our customers.
Executive validation
After summarizing the initial research findings, I defined the initial lo-fi wireframes. I did multiple rounds of lo-fi wires to define the scope of the concept and I brought the concept to an industry event attended by compliance and risk leaders. I personally spoke with VP and Director-level leaders from Bank of Canada, Jefferies, Citizens Bank, and several others. They validated the key pain points we'd identified in the field and were highly enthusiastic about the AI-powered compliance agent experience and confirming we were solving the right problem in the right way.
Design decisions & leadership
Scoping the MVP
After synthesizing the feedback from the event, I drove the decision to limit the MVP to three core capabilities:
Single-product compliance deep dive — instant access to a vendor's full compliance posture
Multi-product compliance comparison — side-by-side evaluation across vendors
Run a security questionnaire — AI-powered framework assessments (SIG, CAIQ) in minutes instead of weeks
Defining scope was the starting point, but the real challenge was designing these features to work naturally within an AI agent paradigm — making the interaction feel conversational and intelligent rather than static and form-like. I went through many design iterations to avoid defaulting to traditional UI patterns, instead creating an experience that understands user prompts, gives contextual responses, and maintains engagement.
The questionnaire assessment flow: a wizard approach
Challenge: The assessment flow involves multiple verification handoffs between our platform, the buyer's email, and the vendor's Trust Center. How do you guide a user through a complex multi-system flow without losing them?
My approach: I initially explored a single-page design to collect all information at once. After collaborating with engineering, I discovered that the agent needs to verify information at each stage before proceeding to the next — the vendor's Trust Center must validate the customer before returning results. This made a linear one-page design technically infeasible.
Solution: I designed a wizard experience that breaks the process into discrete, guided steps:
Buyer selects a product from the AWS Marketplace catalog
Buyer chooses a compliance framework (SIG, CAIQ)
Email-gating verification validates the customer's identity
Buyer can supplement with their own evidence
Agent sends information to vendor's Trust Center for verification
Results are returned step by step
This approach respects both the user's mental model (progressive disclosure) and the system's verification dependencies.
Step 1 Configure assessment
The buyer selects which product to evaluate (e.g., "Datadog Enterprise") and chooses a compliance framework to assess it against either SIG (Standardized Information Gathering) or CAIQ.
Step 2 Add evidence
The buyer chooses how to strengthen the assessment beyond publicly available documents: unlocking the vendor's private Trust Center documents (requires email verification) and/or uploading their own evidence files (PDF/DOCX/XLSX, max 25MB), with a note that files are used only for this assessment and not saved elsewhere.
Step 3 Submit your information
The buyer fills out a short form (name, work email, company, job title, relationship to the vendor, country/region) and agrees to the vendor's Trust Center terms — this is what triggers the identity verification needed to unlock private documents.
Step 4 Enter verification link
The buyer copies a verification link sent to their work email and pastes it back into the flow to unlock access. An inline note clarifies that orgs with an existing NDA get immediate access, while others need to sign one first (via webform or offline) before finishing this step.
Optimizing the NDA Flow: eliminating redundant friction
Challenge: Buyers must sign an NDA to access private compliance documents. The existing flow bounced users across multiple platforms:
AWS Marketplace agent mode → Email → Vendor Trust Center → AWS Marketplace agent mode → Email again → Back to AWS Marketplace agent mode
Each redirect was a drop-off risk.
My initiative: After mapping the end-to-end journey, I identified a redundant verification step. I proposed that once a customer signs the NDA on the vendor's Trust Center and is redirected back to our experience, we immediately unlock the private documents — eliminating the second email verification entirely.
Impact: Reduces platform-hopping, shortens the journey, and directly improves conversion through the NDA gate.
Validation & iteration
I ran two rounds of usability testing (5 participants each) on the compliance deep dive and the security questionnaire wizard. Both scored high on usefulness (4.2–4.4/5), and 100% of participants across both tests said they'd use the tool in their actual work and found it faster than their current process.
Testing also surfaced real friction I fixed before hand off to the dev team, including renaming a confusingly-labeled feature ("Run a framework assessment" to "Run a security questionnaire"), clarifying who receives uploaded evidence, and reframing an unclear "Add evidence" step.
Final design
Lessons learned & what I'd do differently
1. Validate technical constraints early, don't design in a vacuum.
Involve engineering and product from day one — they're not gatekeepers, they're partners. Every project has real constraints technical feasibility, timeline, resources and even the best UX solution to a user problem can hit a wall if those constraints weren't part of the conversation early on. I've learned that engineering and product aren't obstacles to design around; they're the closest collaborators on a project, and the earlier that relationship is built, the fewer costly detours later.
2. Map the full cross-platform journey before optimizing individual screens.
The NDA flow taught me the importance of mapping the end-to-end experience across all touchpoints — not just our product surface. By tracing the buyer's path between our experience, their email, and the vendor's Trust Center, I identified unnecessary friction that wasn't visible when looking at any single screen in isolation. Starting with a journey map rather than screen-level design would have surfaced these opportunities sooner.
3. Reduce platform-hopping wherever possible — every redirect is a drop-off risk.
Each time we push a user to another platform (email, Trust Center, back to our product), we lose a percentage of them. I learned to treat every redirect as a cost and actively challenge whether each handoff is truly necessary. This mindset led directly to proposing the elimination of the redundant verification link in the NDA flow.
4. Break complex flows into progressive steps, but be intentional about where you draw the lines.
The wizard pattern worked well, but deciding where to break steps required understanding both the user's mental model and the system's verification dependencies. If I were to do it again, I'd run a card-sorting exercise with buyers earlier to validate that the step groupings felt intuitive, rather than letting the technical architecture alone dictate the step boundaries.
5. Advocate for simplification with data, not just intuition.
When I proposed eliminating the extra verification step in the NDA flow, having a clear picture of the back-and-forth journey made the case compelling. Going forward, I'd proactively instrument these multi-platform flows to capture drop-off data at each transition point — giving me quantitative evidence to pair with my design rationale when proposing simplifications to stakeholders.
6. Define a clear scope before designing for AI — don't let the possibilities paralyze you.
When I first started designing Trust Agent, it felt like staring at a blank canvas. AI can do so many things that without a clear direction, the open-endedness became overwhelming and slowed my progress. I learned that narrowing the problem space early — defining what the AI should do for this specific use case rather than what it could do — is critical. If I were starting again, I'd set tighter constraints upfront through user research and stakeholder alignment to focus the design effort and avoid getting lost in the breadth of possibilities.