Case study · Financial services
Three weeks against a payments platform
A Series B SaaS company processing payment and account data wanted independent proof its platform would hold before a SOC 2 Type II audit and a Series C raise. External perimeter, AWS, the employee attack surface, and an LLM support agent with tool access.
- Engagement
- External penetration test and adversary simulation
- Duration
- Three weeks
- Client
- Series B SaaS company, around 140 employees, processing payment and account data on behalf of small-business clients. Name withheld under the engagement’s confidentiality terms.
- Authorization
- Scope of work, rules of engagement and a written authorization to test were signed before any testing began. All testing ran from a pre-declared source address range, with a named client contact on standby for the duration.
- Findings
- 2 critical
- 2 high
- 2 medium and low
- Duration
- 3 weeksExternal penetration test and adversary simulation
- In scope
- 5Environments: perimeter, AWS, employee surface, an LLM agent, phishing
- Findings
- 62 critical, 2 high, 2 medium and low
- Retest
- 30 daysEvery critical and high finding confirmed closed
01 / The problem
The board wanted proof, not confidence.
The company was preparing for a SOC 2 Type II audit and a Series C raise at the same time. Its board wanted independent validation that the platform could withstand a determined external attacker — not a vulnerability scan, but a realistic account of how someone would get in, move, and take data out.
Internal engineering was confident in the controls. That is the normal position, and it is not evidence. The engagement existed to turn one into the other.
02 / Scope
Everything an outsider can reach.
The perimeter, the cloud account behind it, the people with accounts on it, and the assistant that had been given access to all three.
- External network and application perimeter, production and staging
- AWS: identity and access management, object storage, serverless functions, API gateway
- Employee-facing surface: email, single sign-on, VPN
- One internal LLM support agent with tool access
- Authorized phishing simulation against three departments
03 / How the paths connected
Three routes in, three different boundaries.
Taken one at a time, each finding has its own fix. Drawn together, they show three separate routes from outside the company to something worth taking, and each one crossed a different boundary.
The first needed no account at all, only a storage policy. The second ran through the assistant’s own permissions rather than a flaw in code. The third is two high findings read together: a credential obtained by phishing, and a session that a password reset did not end.
No single control would have closed all three. That is the case for testing the perimeter, the cloud account, the people and the assistant in one scope rather than four.
04 / Findings
What we found.
Summarised here at the level the report delivered them. Reproduction steps, evidence and remediation detail stay with the client.
- Critical: Client documents readable without authentication
- Critical: Support assistant disclosed internal data from an injected ticket
- High: A finance pretext produced a working credential
- High: Password reset did not end existing sessions
- Medium and low: Staging reachable from the public internet
- Medium and low: Error responses leaked stack traces and library versions
- 2 critical
- 2 high
- 2 medium and low
- Critical
Client documents readable without authentication
A bucket policy allowed unauthenticated reads, and uploaded objects followed a predictable path pattern. Working out the pattern was enough to reach a subset of client-uploaded documents without ever touching the application or holding an account.
Boundary Public internet → object storage
- Critical
Support assistant disclosed internal data from an injected ticket
Instructions written into the body of a support ticket were treated as instructions by the assistant that read it. It disclosed the contents of its system prompt and, in one case, internal account metadata reachable through a tool it had been granted. No code vulnerability was involved. The access path was the assistant’s own permissions, which is why a scanner and a conventional application test would both have missed it.
Boundary Support ticket → assistant → account metadata
- High
A finance pretext produced a working credential
A phishing pretext aimed at the finance team drew a 40% click-through and one credential submission. One submission is initial access; the click-through rate is context, not the finding.
Boundary Email → employee → SSO
- High
Password reset did not end existing sessions
Tokens issued by the SSO provider stayed valid through a password reset. A stolen session therefore survived the exact incident-response step intended to end it, which turns a contained compromise into an uncontained one while the response is recorded as successful.
Boundary SSO provider → session token
- Medium and low
Staging reachable from the public internet
Staging was internet-facing behind weaker filtering than production: a softer copy of the same application, running the same code, on the way to the same kind of data.
Boundary Public internet → staging application
- Medium and low
Error responses leaked stack traces and library versions
Two internal API endpoints returned stack traces and library versions in their error responses, handing an attacker the dependency inventory they would otherwise have to guess at.
Boundary Internal API → error response
05 / The finding that changed the scope
The assistant was an access path, and nobody had tested it as one.
The support agent read tickets written by customers and could call internal tools to answer them. Text in a ticket reached the model as input, and the model could not tell that input from its own instructions. Content written by an outsider became a direction the assistant followed.
There was no vulnerability to patch. The system behaved exactly as built. What failed was the architecture around the model: the assistant held a broader identity than the person it was answering for, and nothing between the ticket and the tool call asked whether that particular request was in bounds.
The fix was not a prompt patch. It was a guardrail layer — input handling, scoped tool access, and filtering on what the assistant was allowed to return — rebuilt with the client’s engineers and retested against the same cases. This is what an AI security assessment covers.
06 / Remediation and retest
We did not hand over a PDF and leave.
Findings were delivered within 48 hours of the end of testing: a prioritized report giving severity, exploitability, business impact and fix guidance for each one, plus a 90-minute readout with engineering and security leadership.
The object-storage exposure and the assistant finding were worked alongside the client’s own team as they happened, because both carried immediate compliance and customer-trust consequences and neither improved by waiting for a document.
A retest 30 days later confirmed every critical and high finding closed, including the rebuilt guardrail layer rather than a surface-level patch. The full engagement sequence is here.
- 01Testing
Three weeks
Perimeter, AWS, the employee surface and the support assistant. The storage exposure and the assistant finding were worked with the client’s team as they happened.
- 02Findings delivered
Within 48 hours
A prioritized report giving severity, exploitability, business impact and fix guidance for each finding.
- 03Readout
90 minutes
Walked through with engineering and security leadership.
- 04Retest
30 days later
Every critical and high finding confirmed closed, including the rebuilt guardrail layer.
07 / Outcome
What it was worth.
- The audit
- The client passed its SOC 2 Type II audit, with the engagement report cited as evidence of a functioning security testing programme. Red Cell holds no certification and issues none; the audit and its result belong to the client.
- A permanent change of scope
- The assistant finding became a standing AI red-teaming addendum to the client’s annual testing scope. Every model or agent change is now retested before it reaches production.
- Nothing left behind
- No finding was disclosed publicly or to any third party. Every engagement artefact was deleted from Red Cell systems at contract close, under the confidentiality terms.
08 / Confidentiality
Publication terms
This account has been generalized and identifying information removed to protect client confidentiality, consistent with Red Cell’s standard engagement terms. The client is not named, the systems are described by category, and no evidence, reproduction step or working technique appears here.
Available on request, with the client’s permission: a sanitized report excerpt, the methodology used, and references.
Tell us what you need to test.
Send the systems, the timing and the constraints. You get a scoped proposal, not a sales sequence.