Interview prompt
In security operations, much of the work depends on skilled human judgment. Demand is growing faster than hiring can keep up, and practitioners who do it well are scarce, expensive, and hard to retain. What SOC workflow(s) would you transform using an AI capability and why? Pick at least one.
AfterShield: make every verified attack harder to repeat
An Amazon-style working-backwards PRFAQ · Prepared by Susie Fan · October 6, 2026
Status: proposal. The press release describes a possible future product; AfterShield's proposed launch, customer results, and commercial assumptions are not established facts. The named AfterShield customer and quotation are fictional illustrations. Other named quotations are from earlier public accounts of industry workflows and do not imply endorsement of AfterShield.
Press release: proposed future announcement
AfterShield turns a verified attack into protection for today's services and tomorrow's releases
(Mountain View, California, January 2027) AfterShield today introduced an autonomous, governed system that helps security and engineering teams keep a stopped attack from working again. AfterShield explains how the team discovered the incident, what happened, and what actually stopped the attack. With an incident commander's approval, AfterShield checks where the same weakness could remain in services running now and in changes waiting to ship, then proposes safeguards that owners can test, approve, and verify over time.
Know what happened. Today, an analyst can close an incident with a conclusion another analyst cannot reproduce. James Dorgan, then a principal incident responder on Coinbase's security incident response team, wrote that “there’s often a considerable difference between how individual analysts investigate the same alert.” The Incident Evidence Agent will gather and reconcile case evidence, test competing explanations, flag unresolved facts, and produce a source-backed account of how the team found the attack, what happened, and what stopped the attack. Once the incident commander approves the account, AfterShield starts the live-service and release checks.
Find the same weakness in services already running. Stopping the known attack and fixing its affected system may still leave the same weakness in another live service the attacker never reached. The Live Defense Agent will turn the verified attack path into targeted checks across other relevant production services, skip services already proven safe, and raise tested change requests for any remaining exposure. Each request goes to a named production owner, who approves the fix before AfterShield changes a live service.
Ship without repeating an old attack. Teams can lose an attack's lesson before the next release. Michael Recachinas, a staff security engineer at GitHub, described an ownership problem during security remediation: “we had no clear way to route remediation work.” The Application Security Agent will analyze code-complete release candidates in the production environment, accessible only to allowlisted test accounts, against verified past attack patterns. The agent will run controlled checks, identify specific security risks, and raise change requests (CRs) containing tested code or configuration fixes. Product and engineering owners approve each CR before the fix reaches production or the release opens to customers.
“Before AfterShield, our five-person security team had to piece together what happened across multiple tools. We stopped the attack, but the follow-up to check other services and the next release often had no clear owner, leaving the same weakness for an attacker to find again. Now one analyst can drive that work with the AfterShield agent inside Claude Code, which our security analysts already use. AfterShield routes tested change requests to the right owners, who still approve every production change,” said Maya Chen, SOC analyst at Northstar Commerce.
Organizations can access AfterShield through an annual enterprise subscription of $75,000 per organization with no per-user seat limit. Security analysts can work with AfterShield inside Claude Code, while approvers can use the existing case and change-management workflow. A security administrator connects the existing security console, service inventory, code repository, production release gate, recovery tools, and change-management workflow. AfterShield creates tested change requests for production services and future releases; designated owners approve every production-changing action before execution. Customers who cancel within 30 days of activation receive a full refund.
Customer FAQs
1. What is AfterShield in one sentence?
AfterShield is an AI-powered security service that turns a verified attack into tested, owner-approved fixes for live services and future releases so the same attack is less likely to harm customers again.
2. How does AfterShield protect services customers use today?
The incident responder still stops the active attack and remediates affected systems through the existing response process. For each approved attack memory, the Live Defense Agent asks a different question: Could the same weakness work in another service already running? The agent maps the verified failure conditions to the customer's authorized service inventory, runtime configuration, identity permissions, deployed versions, network exposure, and relevant telemetry. It excludes services whose existing remediation has been verified, runs read-only checks or safe simulations on relevant remaining services, and compares results with existing scanner findings. For example, after the responder revokes an overprivileged deployment account used in the incident, Live Defense checks other live deployment accounts for the same excessive permission. The agent opens a tested change request with a named production owner and rollback plan for each confirmed exposure, then retests after the owner approves and applies the fix. If no other service shares the failure mode, this branch ends with a recorded negative result.
This is a conditional, targeted replay of a known, verified failure mode, not a second attempt to fix the original affected system or a promise to discover every vulnerability in production. If a service is missing from the inventory or a log source is unhealthy, the agent marks the assessment incomplete.
3. How will AfterShield test a future release without exposing customers?
The Application Security Agent analyzes code-complete release candidates deployed behind a release gate in the production environment. Only allowlisted test accounts can reach the candidate; real customers remain on the approved version. The agent compares the candidate with approved attack memories derived from verified past incidents and with existing scanner findings. The agent runs controlled, non-destructive checks using test accounts and synthetic data, identifies specific code or configuration risks, and raises change requests with proposed fixes, test results, and a rollback plan. Product and engineering owners approve deployment of the gated candidate and each fix before the fix is deployed. They approve opening the release to customers only after the security check passes. The Application Security Agent does not merge code or approve a launch.
4. What happens from an incident to a lasting safeguard?
Illustrative case, not a customer result: An attacker uses a deployment account to run an unauthorized script on a payroll server. The responder revokes that account and remediates the affected server through the normal incident process. The Incident Evidence Agent reconstructs the discovery, attack path, and response; the incident commander approves the account and the resulting attack memory. If other live services use similar deployment accounts, the Live Defense Agent checks them for the same excessive permission and creates change requests with tested fixes. If payroll service was disrupted, IT follows the recovery runbook and the service owner accepts a safe return. The Application Security Agent tests a related code-complete release behind a production release gate using allowlisted test accounts and creates change requests for any repeated weakness. Product and engineering owners approve the fixes and customer exposure. AfterShield checks that approved safeguards remain effective. Appendix A2 shows each step and owner.
If the alert is benign, the analyst documents and closes the alert without creating attack memory or triggering recovery. A shift handoff may occur anywhere but is a side task, not a mandatory journey step.
5. What can AfterShield do on its own, and what requires approval?
AfterShield can gather bounded evidence, challenge explanations, draft an incident timeline, inspect authorized services and repositories, run read-only checks, test code-complete release candidates with allowlisted production test accounts, validate proposed fixes in isolation, create change requests, and verify approved controls. The agents can pursue these steps without a prompt at every step. AfterShield records each read, test, and proposed action in an audit trail.
A designated person approves factual conclusions and every production-changing action. The incident commander approves the incident account; AppSec approves the attack memory; the production owner approves live-service changes and recovery; and product and engineering owners approve gated candidate deployment, fixes, and customer exposure. AfterShield can execute an approved action only through a scoped integration, then checks whether the action had the intended effect. Least-privilege identities, per-connector scopes, budgets, an interrupt path, and deterministic validation limit agent autonomy. Missing or conflicting evidence stops a decision instead of producing an invented verdict.
6. What happens if AfterShield is wrong or the evidence is incomplete?
The case display separates observed facts, inference, unknowns, and actions. The display shows alternative explanations and gaps in source coverage. The incident commander approves the final incident account; AppSec approves a testable memory; the production owner approves a change; and service/release owners accept outcomes. Every memory has an owner, version, scope, review date, and a trigger for reevaluation when architecture or attack behavior changes. Reviewers can dismiss findings with a reason that AfterShield preserves for the next run. We will measure false positives, missed known patterns, unsafe recommendations, and human rework. An agent that stops or remains uncertain should leave a useful, auditable partial case, not an invented verdict.
7. Will AfterShield work with our existing security and development tools?
We propose an independent service with connectors to the existing SIEM/XDR/EDR case and telemetry, identity and cloud tools, recovery platform and service runbook, asset/service inventory, ticketing system, code repository, and production release gate and test-account service. Analysts can invoke and inspect AfterShield from Claude Code through a scoped integration; the case record remains available in the security console. The responder acts in approved response tools; IT restores through the recovery product; product and engineering owners review proposed fixes in their change-management workflow. AfterShield maintains a linked incident ID, evidence pointers, approved attack memory, control/test ID, owner, and verification state across these tools. AfterShield creates change requests in the customer's normal workflow and waits for the designated owner to approve production changes. Customers can connect the services and repositories they authorize without replacing their SIEM, SOAR, EDR, backup platform, or code scanner.
8. How does AfterShield handle sensitive incident data?
We will validate this design with customers: keep raw logs and code in the customer's approved systems where practical; fetch only the evidence AfterShield needs; redact secrets and personal data before model use; scope retrieval and retention by tenant and role; record model inputs and outputs for audit under the customer's policy; and allow memory deletion or revocation. Customers will keep production credentials in their existing secret and change-management systems. AfterShield must treat incident notes, logs, repository content, and pull-request text as untrusted data, not instructions that can override AfterShield's permissions. These are required product controls, not claims of implemented compliance or certification.
Internal FAQs
9. What SOC workflow(s) are you transforming using an AI capability and why?
We will transform what the security team does after it confirms an attack: explain how the attack happened and how it was stopped, find the same weakness in other services customers use today, and keep that weakness out of future releases. Today, those jobs pass between security, operations, and engineering. Important details can stay buried in separate tools, and follow-up fixes can lose their owner. AfterShield will carry the lesson from the incident through to a tested change request for each service or release that needs attention.
AI makes this possible because each attack leaves a different trail across alerts, system activity, service settings, and code. AfterShield will connect those facts, work out where the same attack path could succeed again, and prepare focused checks and fixes. The security and engineering owners will review the evidence and approve changes before they reach customers.
We chose this workflow because the value lasts beyond the incident itself. Every attack becomes a chance to protect the rest of the business, reduce the risk of repeat disruption, and give a small security team the reach of a much larger one.
10. Which products compete with AfterShield, and what gap remains?
SentinelOne Purple AI investigates threats, correlates evidence, builds timelines, and can initiate governed responses through Hyperautomation. Cortex XSIAM prioritizes cases and builds an attack story; Cortex Cloud can open fix pull requests for application-security findings. GitHub CodeQL and Copilot agentic autofix detect supported code-security issues and can validate a fix and open a pull request. Semgrep Memories retains organizational security decisions. Veeam, Cohesity, and Rubrik support recovery. Other platforms cover parts of investigation and case coordination. These are vendor-described capabilities, not comparative performance results.
No product in the reviewed documentation demonstrates one governed workflow that turns a confirmed customer attack into a reusable test, checks both already-live services and allowlisted release candidates in production, opens tested change requests for both, and verifies that approved safeguards endure. Customers may assemble parts of this workflow themselves, so we will test the gap against existing implementations. The closest published dollar proxy is $1.5m in modeled three-year present value from reduced software-attack costs in a vendor-commissioned Forrester/Veracode study. That figure does not estimate AfterShield's incremental value. Appendix A4 contains the complete competitive opportunity comparison.
11. Who performs this work, and which customer segment should we serve first?
An SOC (Security Operations Center) watches for attacks, investigates warnings, and coordinates response. The SOC analyst investigates; the incident responder directs steps to stop harm; IT/SRE restores systems; the service owner accepts a safe return; and AppSec and developers protect current applications and future releases. In a small organization, one person may hold several roles.
We will first target an internal-led SOC at a company with a critical customer-facing application, named recovery and AppSec owners, and regular code review. That organization can authorize access to the incident, live service, and related repository, then judge whether the same attack path is closed in each. The likely buyers are the CISO and the executive accountable for service availability. Other distinct segments are co-managed SOCs (company and provider share command), provider-led SOCs (an MDR/MSSP directs response), and organizations without a dedicated SOC (IT or security generalists own incidents). Regulated and high-consequence operations cut across these segments.
12. What customer pain does the research journey show?
Today an analyst reviews alerts in a security console, a responder uses endpoint and identity tools to stop an attack, IT uses recovery tools to restore a service when needed, and AppSec reviews code later. A closed security ticket may coexist with an unverified containment step, an unavailable service, or a vulnerability still present in production and the next release. Firsthand accounts from r/sysadmin and r/cybersecurity describe recovery friction, weak AppSec ownership, and poor security-to-application handoffs.
The research flowchart shows the full path, conditional recovery, and the learning loop. The chart cards contain original firsthand excerpts, provisional 1–10 pain scores, and shares of 226 selected source records. Those shares describe a purposive complaint collection, not market prevalence or how often a step occurs. Theme counts overlap when one source describes more than one theme.
Appendix A1 contains theme and activity counts, pain scores, and chart-shading rules. Counts are not additive because one record can describe several activities. Restoration and proactive hunting are conditional paths.
13. What tech stack are you planning to use to build this product?
We propose a customer-approved, tenant-isolated service with connectors to existing security, recovery, code, test, and change-management tools, plus a scoped Claude Code integration for analysts. A model-agnostic reasoning layer drafts incident explanations and candidate safeguards; deterministic checks verify evidence, permissions, test results, and approval state. An auditable workflow engine coordinates all three agents and pauses at each human decision gate. We will choose specific model and hosting providers after customer data-residency and evaluation requirements are known. The durable product asset is the verified attack-to-control workflow and evidence graph, not a particular model API. Appendix A3 contains the proposed technical architecture.
14. How will AfterShield generate revenue, and how large could revenue become?
We propose an annual enterprise subscription of $75,000 per organization that includes all three agents and has no per-user seat limit. Expansion is tied to additional protected services, repositories, and test volume. We will not meter approvals or charge for each change request; those actions are central to a safe workflow. Customers use their existing Claude Code access for that optional interface. Customers who cancel within 30 days of activation receive a full refund. The illustrative scenario reaches 300 paying customers at Year 4 end, or $22.5m in ending annual recurring revenue. With customers added evenly through the year, Year 4 recognized revenue would be $15.75m. The scenario assumes no churn, refunds, or pricing changes. It is an aggressive growth case, not a forecast or evidence of willingness to pay. Buyer interviews and paid design-partner evaluations must establish price, sales capacity, adoption, and retention. Appendix A6 shows the four-year customer and revenue schedule.
15. Is $75,000 a credible price, and why not $180,000?
$180,000 is too high as an unproven starting price. Primary posted offers show Prophet AI SOC Analyst at $50,000 per year for 5,000 investigations with $10 overages, Exaforce's Agentic SOC Starter Pack at $75,000 per year, and Legion's AI SOC annual contract at $120,000 per year. The Exaforce and Legion listings do not define exactly what one purchased unit covers. On the AppSec side, GitHub Code Security and Semgrep Code Teams each publish $30 per active committer or contributor per month, equivalent to $18,000 a year for 50 contributors before other products or usage. None covers the same full workflow as AfterShield, and posted offers are not negotiated deal prices.
We propose $75,000 per organization per year with no per-user seat limit, all three agents, and the 30-day refund. The price competes with published AI SOC entry offers without treating code scanning alone as the benchmark. Expansion should follow protected service and repository scope, not the number of analysts or approvers. We will test $75,000 against a higher offer in paid design-partner conversations and require evidence of accepted safeguards, fewer repeated exposures, and renewal before claiming pricing power. Appendix A7 audits the public price records and their limits.
Why no 50-seat bundle? The SANS 2025 SOC Survey finds 2–10 people is the most common size for a fully staffed SOC. AfterShield's work also crosses the SOC, AppSec, engineering, and service ownership, so a 10-seat cap would exclude people who must review a finding or approve a fix. A 50-seat allowance would be arbitrary and would make access planning more important than the security outcome. Tines' current platform pricing includes unlimited users, spaces, and connectors in its paid editions, while Prophet's posted AI SOC offer meters investigations. We therefore propose unlimited named users within the customer organization, governed by SSO and role-based permissions, and commercial expansion by protected scope and controlled-check volume. This is a packaging hypothesis, not a measured optimal seat count; buyer interviews must test whether usage boundaries are understandable and economically sound.
16. Why now, and what is the north star?
Scarce expertise is the constraint. ISC2's 2025 workforce study surveyed 16,029 practitioners and decision-makers; 59% reported critical or significant skills needs, and 88% reported at least one significant security consequence from skills deficiencies. In IBM/Ponemon's 2026 breached-organization study, the average global breach cost was $4.99m. Neither figure forecasts this product's savings. AI-assisted investigation and code review are maturing, while the business still needs to know that the service is safe now and that the same weakness will not ship again.
North star: Every verified attack should end in a safe return to service and make both today's production systems and the next relevant release harder to attack. The SOC protects customers and the business; closing alerts is only one step.
17. What business outcomes do we seek, and how will we measure them?
We seek the same three outcomes as the earlier proposal, extended to live-production prevention:
| Business outcome | Outcome measure | Required guardrail |
|---|---|---|
| Less customer disruption | Total hours a named critical service is unavailable or materially impaired from eligible security incidents; also report substantiated lost transactions, revenue, and service credits. | The service owner accepts functional and security checks before a return is counted. |
| Fewer repeat attacks | Share of relevant production services and later releases that still contain an approved, previously exploited failure mode; track actual recurrence separately when enough time has passed. | Replay historical cases; report missed patterns, false-positive change requests, and release delays. Early evaluation cannot prove a lower real-world attack rate. |
| More verified resolutions with scarce experts | Number and share of eligible incidents that reach verified containment and, if needed, accepted restoration with agent assistance and required human approvals, without reopening for the same harm in the agreed follow-up window. | Report human rework, wrongful containment, reinfection, and incomplete evidence. A recommendation or submitted command is not a resolution. |
We will also observe leading evidence, approved attack memories, live services checked, related releases checked, durable controls accepted, and test pass/fail results, but these are not substitutes for business outcomes. Baselines must compare similar case types and severities, and denominators must include failures and escalations.
18. What must we build and prove before launch?
The proposed January 2027 launch includes all three agents, checks of live services and gated release candidates in production, tested change requests, and human approval before any production-changing action. Before launch, we will validate explanations against source evidence, replay known attack paths first in isolation and then with allowlisted production test accounts, test proposed fixes, and exercise approval and rollback paths with design partners. We will compare AfterShield's checks with existing CodeQL and Semgrep rules, cloud posture findings, and customer runbooks. Appendix A5 gives the build and validation sequence.
Prelaunch evaluation must show that AfterShield correctly explains discovery, attack, and response; that an approved attack memory finds a relevant weakness in a live service or gated release; that the proposed test reproduces or rules out that failure mode; and that owners can approve a tested change request without excessive false positives or unsafe actions. We will measure human work, waiting, rework, coverage, decision quality, and outcomes separately. Rare major incidents require longer observation before we can claim a lower real-world attack frequency. If the agents cannot produce reliable evidence or create noisy, risky changes, we will narrow or stop the work.
19. What research and artifacts support this proposal?
The existing three-agent proposal supplies the baseline customer segments, journey, containment, recovery, future-release design, three outcomes, and development sequence. The competition-adjusted value report supplies the revised priority and consulting-study proxies. The 226-record master research set, source-level coding audit, all Step 01 excerpts, journey audit, and community search log support the public-source findings. A separate primary-source note compares NIST and CISA incident-response duties with AfterShield's conditional check of other live services. The two named industry excerpts in the press release come from James Dorgan's Scaling Detection and Response Operations at Coinbase Pt. 1 (2023) and Michael Recachinas's How GitHub Gave Every Repository a Durable Owner (2026). Those authors describe their organizations' experiences and do not endorse AfterShield. The interactive AfterShield prototype demonstrates the proposed incident explanation, live-service check, gated release check, and owner approvals with fictional data. We had no private customer interviews, live integration, or field experiment for this proposal.
20. What should AfterShield’s interface make easy to judge?
The analyst should see discovery, attack path, response, and uncertainty on one timeline and open the underlying source for every conclusion. The incident commander should be able to correct a claim without rewriting the whole explanation. AppSec and production owners should see one proposed control at a time: the incident evidence behind the control, where the control applies, the test result, the expected business effect, the affected service or repository, the owner, and the approval needed. A status of unverified, ready, blocked, failed, or accepted should refer to an actual check or owner decision, not model confidence alone. Design partners should test whether the interface is understandable during a live incident and useful weeks later at release review.
Appendix
A1. SOC journey source counts and pain coding
The percentages below describe the selected 226-record complaint collection, not market prevalence or step frequency. A source can appear under more than one journey activity. The flowchart uses pain to set the color and complaint share to lighten or darken the shade.
| Journey theme | Selected records | Role in this proposal |
|---|---|---|
| Watch & Hunt | 41/226 (18%) | Monitoring and source-health evidence must be trustworthy. |
| Manage the Queue | 25/226 (11%) | The analyst chooses a case; queue sorting is not our main product. |
| Investigate | 39/226 (17%) | A verified case becomes the source of the incident explanation. |
| Stop Harm | 24/226 (11%) | The responder stops the active attack; AfterShield uses the verified result as evidence for repeat-exposure checks. |
| Restore Service | 9/226 (4%) | Conditional, very painful work; a service owner accepts safe return. |
| Explain & Prevent | 39/226 (17%) | Primary workflow: turn a verified incident into lasting safeguards. |
| Journey activity | Complaining records / 226 | Pain / 10 | Shade treatment |
|---|---|---|---|
| 01 Make sure monitoring works | 35 (15%) | 8 | Darkened |
| 02 Open the incident queue | 8 (4%) | 1 | Lightened |
| 03 Choose what needs attention | 23 (10%) | 7 | Base |
| 04 Gather the facts | 22 (10%) | 8 | Base |
| 05 Decide what happened | 15 (7%) | 9 | Base |
| 06 Find how far the attack spread | 4 (2%) | 9 | Lightened |
| 07 Get the right people to act | 12 (5%) | 7 | Base |
| 08 Stop harm and check result | 13 (6%) | 8 | Base |
| 09 Restore services safely | 9 (4%) | 10 | Lightened |
| 10 Record and explain outcome | 21 (9%) | 5 | Base |
| 11 Learn and prevent repeat | 18 (8%) | 6 | Base |
| 12 Hunt without an alert | 6 (3%) | 6 | Lightened |
A2. Detailed illustrative customer journey
The payroll-server example is hypothetical. Restoration occurs only when the incident disrupts service.
| Moment | What the people and system do |
|---|---|
| Detect and explain | The SOC analyst opens the existing case. The Incident Evidence Agent gathers endpoint, identity, cloud, and service records, reconstructs how the warning was discovered, tests alternate explanations, and shows where evidence is missing. The commander verifies the attack path and affected payroll service. |
| Stop and verify | The responder approves isolation or account revocation in the existing tool, then checks the tool result and fresh behavior. If the account still signs in or the host still reaches attacker infrastructure, the case stays open for human action. AfterShield records the verified outcome for the incident explanation. |
| Restore if needed | The IT lead uses the existing backup tool and tested payroll runbook. The payroll owner tests a real transaction and data integrity; security checks for renewed attacker access. The owner accepts or rejects return to service. AfterShield records the evidence and the owner's decision. |
| Approve the lesson | The incident commander and AppSec engineer approve an attack memory: the unauthorized deployment path, the trust boundary, and a test that would have caught the attack. |
| Check other production services, if relevant | The Live Defense Agent searches other live deployment accounts and services for the same risky permissions. The agent skips services already verified safe, opens change requests with tested fixes for confirmed exposures, and reruns checks after the production owner approves and applies the fixes. If no other service shares the failure mode, the agent records that result and moves on. |
| Check the next release | Once product and engineering owners approve deployment of a code-complete candidate behind the production release gate, only allowlisted test accounts can reach it. The Application Security Agent runs approved, non-destructive checks against the verified attack memory and raises a change request with a proposed fix if the candidate repeats the weakness. Product and engineering owners approve the fix and customer exposure. |
| Verify durability | AfterShield checks whether the production control remains active and the release test remains in place. AfterShield reopens the prevention task if either check fails or disappears. |
A3. Proposed launch architecture
These choices describe a proposed implementation, subject to customer data-residency and evaluation requirements.
The production release lane runs controlled checks only against a code-complete candidate that owners have approved for gated deployment. Only allowlisted test accounts can reach that candidate; owners approve fixes and broader customer exposure separately.
| Layer | Planned choice | Purpose |
|---|---|---|
| Customer interface and API | Scoped Claude Code MCP integration for analysts; TypeScript/React case and control views for reviewers; Python/FastAPI service | Let analysts drive evidence and prevention work where they already work, while showing traceable claims, owner decisions, production findings, and release checks. |
| Connectors | Scoped adapters for the customer's SIEM/XDR, endpoint and identity tools, cloud inventory, ticketing, Git repository, production release gate, allowlisted test-account service, change-management system, and recovery platform | Reuse existing systems of record, create reviewable change requests, and execute approved actions only within granted permissions. |
| Agent workflow | Python workers with Temporal workflows | Persist multi-step work, retries, waiting for approvals, and recovery from worker failure. |
| Evidence and memory | PostgreSQL for cases, approvals, and versioned attack memories; encrypted object storage for permitted artifacts; retrieval index only where needed | Keep cited source pointers and an auditable memory lifecycle. Raw logs stay in customer systems when practical. |
| Reasoning and validation | Model-agnostic LLM gateway; structured tool calls; independent evidence/contradiction checks; isolated fix-validation runners; controlled, non-destructive production release checks; existing CodeQL custom queries where suitable | Draft explanations and targeted tests, then verify them against records and executable checks rather than trusting prose. |
| Permissions and audit | Customer SSO/OIDC, scoped service identities, cloud KMS, Open Policy Agent approval policy, and OpenTelemetry traces/logs | Enforce least privilege, record every agent step, and require approval for production-changing actions. |
A4. Full opportunity ranking and dollar proxies
Impact uses provisional pain bands: Very high = 9–10; High = 7–8; Medium = 4–6; Low = below 4. The published dollar figures are rounded, three-year modeled present-value proxies from vendor-commissioned consulting studies. They are not estimates of AfterShield's value, and differing study scopes prevent direct comparison or addition. Current market solutions are examples of vendor-described capabilities, not independent performance comparisons. Market gap is a hypothesis about the specific workflow.
| Priority | Journey bucket | Impact and published dollar proxy | Current solutions in the market | Market gap | Opportunity decision |
|---|---|---|---|---|---|
| 1 | Explain & Prevent | Medium · $1.5m PV avoided software-attack cost in a broader AppSec model (Forrester/Veracode). | Purple AI explains incidents; GitHub Copilot Autofix proposes code fixes; Semgrep Memories retains security decisions. | High | Incident explanation → approved memory → check production and future releases. |
| 2 | Restore Service | Very high · $0.1m PV modeled disruption avoided by a recovery product (Forrester/Dell). | Veeam Recovery Orchestrator and Cohesity RecoveryAgent plan, test, and coordinate recovery. | Medium | Verify whole-service safe return with existing recovery tools. |
| 3 | Stop Harm | High · $2.1m PV modeled response labor savings from broader endpoint protection (Forrester/Broadcom). | SentinelOne Hyperautomation and Cortex XSIAM run governed response workflows. | Medium | Verify the security effect of approved containment. |
| 4 | Investigate | Very high · $1.2m PV modeled case-management efficiency, including remediation (Forrester/Palo Alto Networks). | Purple AI builds evidence-backed incident timelines; Cortex XSIAM correlates activity into cases. | Low | Use verified outputs of existing investigation tools. |
| 5 | Watch & Hunt | High · $2.8m PV broad modeled breach-risk reduction (Forrester/Google). | Google Security Operations and Cortex XSIAM support threat detection and hunting. | Low | Source health is a prerequisite; do not lead with another detection platform. |
| 6 | Manage the Queue | Medium · $0.9m PV modeled tier-1 triage efficiency (Forrester/Palo Alto Networks). | Microsoft Sentinel and Cortex XSIAM group, prioritize, and assign incidents. | Low | Integrate with the existing queue. |
A5. Prelaunch build and validation sequence
All three agents and human approval of production change requests belong in the proposed launch. The stages below describe development and validation before the launch, followed by broader deployment.
| Stage | We will do | Continue only if... |
|---|---|---|
| 0. Validate | Walk through 10–15 past incidents and related live services/releases with 3–5 design partners; identify the real owner, existing controls, and loss baseline. | A repeatable attack mechanism has a production or release check that customers do not already perform well. |
| 1. Explain and remember | Connect one case source and one repository; reconstruct discovery, attack path, and verified response; have the commander/AppSec approve one testable memory. Replay known historical cases. | The record is evidence-complete, reviewer-corrected, and specific enough to generate a useful check. |
| 2. Check production and the next release | Run read-only checks across authorized live services; validate approved tests on historical cases, then use allowlisted test accounts against gated, code-complete release candidates in production. Raise owner-specific change requests with tested fixes. | The agent catches known relevant weaknesses with acceptable noise, safe permissions, and a named owner for each fix. |
| 3. Verify response, recovery, and approvals | Evaluate endpoint and identity containment actions in shadow mode; exercise critical-service recovery plans in isolation; test the full change-request path and human approval gates for production and release fixes. | Responders find useful incomplete-action alerts, owners can verify safe return, and no production-changing action bypasses approval. |
| 4. Scale after launch | Add incident patterns, services, integrations, and repositories where measured outcomes justify them. | Repeat exposure and disruption decline, verified resolutions rise, and customers pay, renew, or expand. |
A6. Illustrative four-year revenue projection
This is an aggressive growth scenario, not a forecast or evidence of willingness to pay. The model assumes an annual subscription of $75,000 per organization with no per-user seat limit, customers added evenly within each year, no churn, no exercised 30-day refunds, and no price change. Recognized revenue = average paying customers during the year × $75,000. Ending annual recurring revenue (ARR) = year-end paying customers × $75,000. A sales plan must validate acquisition pace, buyer budget, adoption, and retention.
| Year | Average paying customers | Year-end paying customers | Recognized revenue | Ending ARR |
|---|---|---|---|---|
| 1 | 5 | 10 | $0.375m | $0.75m |
| 2 | 25 | 40 | $1.875m | $3.0m |
| 3 | 80 | 120 | $6.0m | $9.0m |
| 4 | 210 | 300 | $15.75m | $22.5m |
A7. Primary-source pricing benchmark audit
These are public vendor prices or vendor-posted AWS Marketplace offer dimensions checked on October 6, 2026. They are not actual transaction prices, and their scopes differ. A missing unit definition can make the final contract much larger than the listed dimension. The source URLs and capture notes are in the separate AfterShield pricing primary sources research ledger.
| Product and primary listing | Public price | What the price measures | Comparison limit |
|---|---|---|---|
| Prophet AI SOC Analyst, AWS Marketplace | $50,000/year | 5,000 alert investigations; $10 for each additional investigation | Investigation and scoped response, not incident-derived production and release prevention. |
| Exaforce Agentic SOC Starter Pack, AWS Marketplace | $75,000/year | One listed starter-pack unit | Listing does not define what one unit covers; managed service is separate. |
| Legion AI SOC Annual Contract, AWS Marketplace | $120,000/year | One listed annual-contract unit | Listing does not define the unit's team or environment scope. |
| Synack Active Offense AI Bundle, AWS Marketplace | $60,060/year | Annual platform, weekly attack-surface discovery, and ten 10-credit Sara Triage packs | External validation package, not the same incident-to-fix workflow. |
| GitHub Code Security, GitHub pricing page | $30/active committer/month | Code-security coverage; $18,000/year at 50 active committers | Code finding and autofix, not full SOC or live-service protection. |
| Semgrep Code Teams, Semgrep pricing page | Starting at $30/contributor/month | One Code product; $18,000/year at 50 contributors before other products | Enterprise tier is custom-priced; contributor and AfterShield seat populations differ. |
| SentinelOne Singularity Complete, SentinelOne packages page | $179.99/endpoint/year for 5–100 workstations | Endpoint package; enterprise agentic SOC tier requires a quote | Endpoint count and platform bundle do not reveal standalone Purple AI Agentic Investigation price. |
| Torq AI SOC Platform, AWS Marketplace | $450,000/year listed for each plan | Broad platform dimension with an undefined unit | Enterprise-scale upper reference, not an anchor for a new focused product. |
The three closest published AI SOC offer dimensions are $50,000, $75,000, and $120,000 per year. Their midpoint is $75,000, but their included work is not identical. AfterShield's prior $180,000 proposal was 2.4 times that midpoint and required unproven incremental value. The proposed $75,000 price includes all three agents and unlimited named users within the customer organization. Customer-specific protected scope, accepted fixes, disruption avoided, budget ownership, and renewal must determine whether this price is sustainable.
Seat-packaging evidence. The SANS 2025 SOC Survey reports that 2–10 people is the most common size for a fully staffed SOC. That is the core working group, not the total population of AppSec, engineering, production, and incident approvers. Current Tines platform pricing includes unlimited users in its paid editions, showing a relevant automation packaging precedent; Tines Stories has separate published limits, so this is not a claim about every Tines product. Prophet's posted AI SOC offer charges for investigations and overages rather than a fixed analyst-seat bundle. Claude Code's MCP documentation describes how an external service can be exposed as tools inside the analyst's coding environment. None of these sources proves how many AfterShield users a buyer would actually invite. We will test access patterns with design partners, while using role-based permissions and scoped service identities to control authority without charging for each approver.
A8. Verbatim research excerpts
Research summary. The attached Markdown contains one short, attributed verbatim excerpt for each of the 226 selected primary-source records behind the journey. In this collection, 39 records describe investigation friction and 39 describe explaining outcomes or preventing repeat work; some records appear in both groups. Practitioners repeatedly describe missing context, fragile automation, and follow-up work that lacks a clear owner. Three supplemental accounts give concrete examples of AppSec ownership and recovery integration problems. The exact workflow from a confirmed incident to checks across other live services and future releases was not separately counted, so its size and willingness to pay remain hypotheses to validate with customers.
The attachment also includes 12 focused Purple AI and SentinelOne feedback records and 3 supplemental concept-validation records. Those are outside the 226-record denominator. The source collection is purposive and does not measure market prevalence. Each excerpt preserves the wording recorded in the research ledger and links to its original post or article; these are selected excerpts, not full thread transcripts.