Attack-replay and step-up gate for AI support agents handling account recovery, refunds, and entitlement resets.

1. A $64 million Series A, 15x run-rate growth, and existing frontier-lab and Fortune 500 customers show that agent security is already a funded control-plane category.
2. The Reuters-reported Meta support-agent incident proves support automation can create mass account-takeover risk, turning safety theory into an immediate buyer pain.
3. Buyers now expect one system to cover launch readiness and live containment, not separate point tools for testing and runtime monitoring.
4. If enterprises are heading toward more than one billion internal AI agents by 2029, manual approvals and legacy controls will not scale to action-taking support workflows.

Catalyst. Straiker's financing, 15x revenue growth, and the cited Meta support-agent incident show that enterprises have moved from theoretical agent risk to paying for testing and runtime containment of action-taking support workflows.

The product connects to support-agent builders, CRM and ticketing systems, customer-verification tools, and internal admin panels to create a catalog of every state-changing action an agent can take. Before launch, it replays historical tickets plus adversarial scenarios such as social-engineered recovery attempts, refund stacking, and entitlement abuse to show exactly where the agent would overstep. Teams approve an action policy by intent, amount, customer state, and verification strength instead of writing brittle prompt rules. In production, the runtime proxy can force a human review, trigger additional verification, or block the mutation entirely when the action falls outside the approved envelope. Every approved and blocked action becomes evidence for fraud, security, and compliance reviews, giving operators a kill switch without shutting down all automation.

What's different. Fraud systems score end-user behavior, generic agent-governance products watch prompts or permissions, and helpdesk vendors offer canned QA. This company owns the mutation layer where an AI agent actually changes customer identity, money, or entitlements. Its moat becomes a replay corpus of abuse patterns, approval policies, and safe-action baselines across support stacks that incumbents cannot assemble from static rules alone.

Jobs to be done

flowchart LR
  Buyer[Support security team] --> Pain[Risky account and refund actions]
  Pain --> Product[Adversarial release and runtime gate]
  Product --> Outcome[Safer autonomous support actions]

Executive takeaways

• Action-taking support AI is moving from pilot to production, which makes security risk attach to the mutation itself rather than to the chat response alone.
• The sharpest wedge is a neutral control layer for password resets, refunds, and entitlement changes across CRM, help desk, and internal admin systems.
• Native CX platforms and horizontal agent-security startups both validate demand, but neither side yet owns cross-stack support-specific replay testing plus runtime step-up control.
• Public AI-service pricing and automation case studies show enough budget exists to fund a dedicated safety layer once buyers are close to go-live.

Market definition

The relevant market is support-action security for agentic customer service: software that replays risky workflows before launch and enforces approval or block policies when AI agents change account access, money, or digital entitlements in production.

Customer and buyer

Daily users are support-platform, product-security, and trust-operations leaders at consumer platforms using Salesforce, Zendesk, or similar stacks. The economic buyer is usually the CISO, VP of Customer Platform Engineering, or Head of Trust and Safety Engineering, with support leadership as an influential co-buyer.

Buying triggers

• A support organization wants to move from assistive AI to autonomous account recovery, refund, or entitlement actions. [6][10][42]
• A security or trust review follows account takeover, impersonation, or abuse of automated recovery workflows. [103][126][131]
• Platform owners discover that prompt injection, delegated permissions, and weak logging make current go-live controls too brittle. [2][5][16][18][20]

Willingness to pay

Public price points already support a dedicated control-layer budget. Fin charges $0.99 per outcome, Agentforce sells usage through flex credits, Zendesk sells AI-ready suites from $55 per agent per month, and Intercom bundles Fin with paid seat plans. Case studies such as Best Egg show that support AI can already return material savings, making protection spend easier to justify. [43][48][53][72][94]

Category dynamics

Growth signal 1.7x YoY adoption growth in AI service agents (39% to 66%)

Validation signals

• Salesforce reports AI-service-agent adoption rose from 39% to 66% in one year, and 70% of adopters see value within 60 days.
• Service leaders expect AI to resolve half of service cases by 2027, implying action volume and workflow authority will keep rising.
• Fin’s public pricing and simulation tooling show that buyers already pay outcome-based AI fees and care about pre-launch testing.
• Zendesk AI agents already act in authorized systems, and Best Egg reports 80% chat automation using Zendesk AI.
• The Meta support-bot incident proves that weak recovery controls can turn support automation into direct account takeover risk.

Regulatory & technical constraints

• Action-taking support agents inherit powerful delegated permissions, so least-privilege scoping is a product requirement rather than a later hardening step.
• Indirect prompt injection can arrive through emails, documents, and external content, which means replay tests must include hostile-content scenarios, not just happy paths.
• Account recovery and password-reset workflows need identity-proofing and authentication lifecycle policies strong enough for privileged mutations.
• Deployers need human oversight, logging, and data-minimization controls around AI-supported account changes and customer-data handling.

Competition comes from two directions: native support platforms adding observability, testing, and trust features, and horizontal AI-security vendors adding discovery, red teaming, and runtime controls. The open space is a cross-stack mutation gate purpose-built for support workflows where a bad agent action becomes account takeover, refund leakage, or entitlement abuse.

Why incumbents do not win by default

• CRM and help-desk platforms. Salesforce and Zendesk are embedding actions, trust, and pricing directly into their own stacks, but they do not win by default when a buyer needs one control layer across CRM, help desk, and off-platform admin tools.
• Horizontal agent-security platforms. Straiker, Noma, Lakera, and Zenity validate spend on discovery, red teaming, and runtime controls, but their default product posture is horizontal AI security rather than support-mutation policy packs.
• Fraud and identity vendors. Existing fraud and identity stacks help with risky recovery flows, yet they focus on end-user or transaction risk more than pre-launch agent replay and inline AI approval logic.
• In-house QA and read-only copilots. Teams can keep agents assistive-only or build manual review queues, but once agents start updating external systems, simulation, boundary-setting, and evidence retention become too operationally heavy to stitch together ad hoc.

Support Action Replay Gate is a release-control and runtime approval layer for digital consumer platforms moving AI support agents from drafting replies to executing password resets, refunds, and entitlement changes. The urgent pain is that one bad support mutation can become direct account takeover, fraud loss, or entitlement abuse, yet most current controls still focus on prompts, permissions, or post-hoc audits instead of the mutation boundary itself. The beachhead should be gaming marketplaces, subscription apps, and similar consumer platforms with 2-20 million accounts, centralized Zendesk or Salesforce support, and a live program to let agents take account-recovery or entitlement actions. The first product must stay narrow: replay historical tickets and abuse cases for one protected workflow, define an approval envelope by verification strength and customer state, and enforce step-up review or blocking at runtime. Research supports an estimated $330M TAM, $99M initial SAM, and about $5M year-3 SOM for this initial wedge, with expansion into adjacent agent actions that change money, identity, or access. Go to market should start with a paid launch-readiness pilot sold to security and customer-platform leaders through direct sales and support-stack integrators, then convert into an annual contract for one governed workflow plus protected-action usage. The biggest open questions are how quickly target teams will permit action-taking agents in the next 12-24 months and whether browser-only internal admin tools can be governed without brittle implementation. This is strong enough for pre-seed diligence because the incident-driven why now and workflow wedge are real, but the company must prove deployment speed, acceptable false-positive rates, and pilot-to-production conversion before assuming category scale.

Problem

• Support teams can now let AI agents reset passwords, issue refunds, or restore entitlements before security teams can prove which state-changing actions are safe under which verification conditions.
• Generic agent security, fraud rules, and help-desk QA do not provide cross-stack replay, inline step-up control, or evidence at the exact moment an AI agent mutates identity, money, or access.

Solution

• Catalog each support-agent action across Zendesk or Salesforce, verification tools, and internal admin systems, then replay historical tickets and adversarial abuse cases against one high-risk workflow before go-live.
• At runtime, enforce policy by intent, amount, customer state, and verification strength so the system can require human approval, invoke stronger identity checks, or block the mutation while retaining audit evidence.

Why we win

• The wedge sits where budget and downside are sharpest: account-recovery and entitlement mutations where security, fraud, and CX leaders already need a go-live answer.
• Each deployment compounds a proprietary replay corpus, cross-system action graph, and approved-versus-blocked policy history that single-stack vendors and generic governance tools do not natively own.

Milestones

flowchart LR
  Wedge[Account recovery launch gate] --> MVP[Replay engine plus step-up runtime]
  MVP --> Proof[Safe go-live for one protected workflow]
  Proof --> Expansion[More mutations and adjacent operations]

Founding team

Experiment roadmap

Risk assessment

What must be true

• At least 40% of qualified beachhead accounts must plan to let AI agents execute account-recovery, refund, or entitlement actions within 12 months.
• At least half of qualified prospects must identify a cross-stack control gap that native Salesforce, Zendesk, or existing fraud tooling does not solve.
• The packaged first deployment must produce replay evidence and approval recommendations within 30-45 days using Zendesk or Salesforce plus one action system.
• Shadow-mode policies must keep false positives below 10% on legitimate mutations and median step-up latency under 5 minutes.
• Paid pilots must convert to $100k+ production contracts often enough that at least half of early production customers expand to a second protected workflow within 12 months.

Open diligence questions

• Which first workflow produces the best precision-to-ROI tradeoff: password resets, refunds, or digital entitlement restoration?
• How many target accounts have API-accessible admin tools versus browser-only internal consoles that would slow deployment?
• Who owns the budget after pilot approval: CISO, VP Customer Platform Engineering, or trust and fraud leadership?
• What false-positive and approval-latency thresholds will support operations accept before runtime blocking goes live?
• How often do prospects require neutral cross-stack coverage across help desk, CRM, and off-platform admin tools rather than native vendor controls alone?

Model sanity

• Revenue engine. Base-case Y3 revenue comes from converting three Y1 pilots into a 13-customer Y2 base and then adding partner-assisted production customers plus second-workflow upsell to reach 32 customers by Q4Y3.
• Must go right. The packaged deployment path has to keep the sales cycle near six months because sales-cycle slippage is the biggest combined hit to Y3 revenue and cash in the sensitivity table.
• Model breaks if. If action-taking support programs stay assistive-only and production customers stall near 20, the downside scenario drives cash below zero before the next round.
• Next-round proof. The next financing is justified if the company exits Q4Y2 with roughly 13 production customers, visible second-workflow attach, and enough pipeline from partners to support the Y3 ramp.

Scenarios

Sensitivity

flowchart LR
  DesignPartners --> PaidPilots
  PaidPilots --> ProductionCustomers
  ProductionCustomers --> BaseSubscription
  ProductionCustomers --> UsageAndExpansion
  BaseSubscription --> Revenue
  UsageAndExpansion --> Revenue
  Revenue --> GrossProfit
  GrossProfit --> Cash

Flags: Y1 revenue is intentionally lumpy because the model follows the BP sequence of paid pilots converting into annual contracts rather than assuming straight-line SaaS MRR from day one. · The base case depends on API-accessible admin tools and packaged integrations; browser-only back-office workflows would slow deployment and compress gross margin. · Q4Y3 still reaches only modest positive quarterly EBITDA, so the company should raise the next round from Q4Y2 to Q2Y3 proof points rather than waiting for cash to run lower. · Rule of 40 looks unusually high because Y2 revenue starts from a small base; investors should focus more on conversion proof, gross margin progress, and burn multiple.

• Incumbent workflow vendors. Helpdesk, CRM, or agent-builder vendors could add lightweight approval gates and try to absorb the category. Mitigation: Win on cross-system attack replay, fraud-specific policy packs, and runtime evidence across heterogeneous stacks that single vendors do not control.
• Slow move to action-taking agents. Some enterprises may keep support agents in draft-only mode longer than expected, delaying budget for enforcement. Mitigation: Sell shadow-mode testing first to teams already under pressure to automate account recovery or refunds, then expand into runtime controls at go-live.
• Integration and false-positive burden. Connecting internal admin tools and overblocking legitimate actions could slow support operations if deployment is too broad too early. Mitigation: Start with one workflow such as password resets or refunds, learn approval baselines in observe mode, and expand only after precision targets are met.