Manual penetration testing
Every assessment is run by an operator working the system the way an attacker would. Scanners find candidates; findings are ranked by what an attacker actually reaches.
Authorized offensive security · San Diego
Find the attack paths that matter.
Penetration testing, adversary simulation, and AI security assessments. Understand how systems can fail, what is at risk, and what to fix next.
Illustrative assessment modelroute 01
Not a scan, a client system, or a real finding.
02 / How we work
Built around the team that owns the system.
Retest, not just report
One verification cycle for the agreed findings, within the retest scope set in the statement of work, so you know what is actually fixed.
Written for two readers
An executive summary for the people who fund the fix, and technical findings with reproduction steps for the people who make it.
Critical findings, raised when found
You hear about a serious finding when it is found, through the escalation contact named in the rules of engagement — not at report delivery.
Scoped to your system
Scope, objectives and constraints are agreed before testing starts. If a smaller engagement answers the question, that is the one we propose.
03 / Services
Three ways teams bring us in.
Penetration testing
Find the paths into and through a system, and show where each one ends.
External and internal networks, web applications and APIs, and cloud environments. Findings are ranked by what an attacker reaches, not by scanner output.
— Network, application and cloud scope
— Attack paths traced to the affected asset
— Reproduction steps and evidence
More on penetration testing ATTACK PATH TRACING
Each finding is placed on the path from the outside in, and ranked by the asset it ends at, not by how loud the scanner was.Red and purple team
Test the response, not only the surface.
Objective-based operations against agreed targets, or a collaborative exercise run alongside your defenders with detections tuned inside the session.
— Objectives and stop conditions agreed in advance
— Timeline compared against your telemetry
— Detection gaps with the missing signal named
More on red and purple team FLAGSHIP SERVICE
AI red teaming
Assess what the model can reach, and what it can be made to do with that access.
The assessment covers the application, the agent, its permissions, connected tools and the data flowing through it — not the model in isolation.
— Prompt injection through user input and retrieved content
— Tool misuse and excessive permissions
— Cross-user and cross-tenant isolation
AI red teaming in detail 04 / AI red teaming
Your AI has access. Test what it can do with it.
An assistant is rarely just a model. It is an application with a system prompt, an identity, a set of tools it can call, a store it can read from, and a user on the other end whose input becomes part of its instructions.
Every one of those is reachable. An assessment works the deployed architecture — what the agent can be told to do, what it can reach when it does, and what happens downstream when its output is trusted.
// connected tools
An agent that can file a ticket, send a message or call an internal API can be steered into doing it on someone else’s behalf.
// retrieved content
Text pulled from a document store, a web page or a past conversation reaches the model as input. It is not trusted content.
// permissions
Assistants are often given a service identity broader than any single user. The blast radius of one bad instruction follows that identity.
// sensitive data
Retrieval boundaries decide which records a given user’s question can surface. Those boundaries are testable, and often weaker than assumed.
05 / What you receive
The report is the product.
A finding nobody can reproduce is not a finding. Everything is written to be acted on by the team that owns the system.
- Executive summary
- What was tested, what an attacker could reach, and what that means for the business — written to be read by people who will not read the technical findings.
- Technical findings
- Each finding with its affected component, the conditions required, a severity rationale, and reproduction steps a developer can follow.
- Evidence
- Requests, responses, configuration excerpts and screenshots that substantiate the finding, captured and handled under the terms agreed in the statement of work.
- Remediation guidance
- The change that removes the finding, at the level of the control rather than the single request, with a suggested order of work.
- Retest results
- The outcome of one verification cycle for the agreed findings, within the retest scope defined in the statement of work.
06 / Sample finding
What a finding looks like.
Written for two readers at once. The example below is constructed for this page. It is not a client system, a real result, or a working technique. For findings from a real engagement, generalized under its confidentiality terms, read an engagement record.
ILLUSTRATIVE EXAMPLE · RC-EX-001SEVERITY: HIGH
Support assistant returns records belonging to another tenant
- Affected boundary
Support assistant → ticketing API → customer records.
The assistant calls the ticketing API with a service identity that can read every tenant, and the lookup is constrained by the argument the model supplies rather than by the signed-in user.
- Business impact
A customer using the assistant can obtain another customer’s support history, including anything those tickets contain. The exposure is a contractual and regulatory matter before it is a technical one, and it leaves no trace that distinguishes it from ordinary use.
- Remediation
Authorize the tool call rather than the assistant. Pass the signed-in user’s identity through to the ticketing API and enforce tenant scoping server-side, so a request for an out-of-scope record fails at the API regardless of what the model asks for.
- Verification
Retested during the agreed retest window with the same evaluation case, plus a regression check added to the customer’s test suite.
07 / Engagement process
Six steps, agreed before anything is touched.
01
Scope
Agree the assets, objectives, exclusions and operational constraints.
02
Rules of engagement
Fix the testing window, the intensity, the escalation contacts and the stop conditions.
03
Written authorization
Obtain signed authorization to test before any testing begins.
04
Testing
Work the agreed scope inside the agreed boundaries, with progress communicated.
05
Reporting
Deliver an executive summary and technical findings with evidence.
06
Retest
Verify agreed fixes within the retest scope defined in the statement of work.
08 / Buyer questions
Questions we are asked before a first engagement.
How is scope decided?
You bring the systems and the objective; we turn that into a defined scope with explicit exclusions and constraints. Scope, exclusions and the testing window are recorded in the statement of work before anything begins.
What authorization do you need?
Written authorization to test the specific systems in scope, signed by someone able to grant it. Where a system is hosted or operated by a third party, we confirm that provider’s own authorization requirements before testing touches it.
Do you test production systems?
Often, because that is where the real configuration lives. Production testing is agreed in advance with a defined window, agreed intensity, named escalation contacts and stop conditions. Where the risk to availability is not acceptable, we test a representative environment and say clearly what that changes about the results.
What does an AI assessment actually cover?
The deployed system around the model: the application, the agent, its permissions, connected tools, retrieval boundaries and the handling of model output. Model-only probing without that context tells you very little about your own risk.
What do we receive at the end?
An executive summary, technical findings with evidence and reproduction steps, remediation guidance, and the results of the agreed retest. The report is structured to be readable by an auditor or a customer security reviewer as well as by your engineers.
Is retesting included?
One verification cycle for the agreed findings is included, within the period and scope defined in the statement of work. It confirms whether those specific findings are resolved. It is not unlimited retesting.
Can a report be used as compliance evidence?
Testing can support compliance evidence and customer assurance requirements. Scope and evidence mapping depend on the applicable requirements, so we agree what the report has to demonstrate before testing starts rather than after.
Tell us what you need to test.
Send the systems, the timing and the constraints. You get a scoped proposal, not a sales sequence.