Cybersecurity
Security engineering for the AI systems we build: threat modeling, identity for agents, data boundaries and the audit evidence a review asks for.
A CTO signs the proposal. A CISO decides whether it ships. This page is written for the second reader. When an AI system reaches security review, the questions are always the same: what can this system reach, what leaves your boundary, who approved the action, and can you prove any of it later. We design for those questions before the architecture is fixed, not after a review sends the build back.
The threat model comes before the architecture
Most AI security problems are architectural rather than incidental. A retrieval system inherits the access of whatever it indexes. An agent that can call a tool can take an action someone will have to answer for. Any text the system reads, including a document, an email or a web page, is an instruction channel an attacker can write to. We work those paths through before the design is settled, and we write the result down: the assets in reach, the untrusted inputs, the actions the system can take, and what an attacker gains by influencing each one.
Identity and permission for agents and tools
An agent is not a user, and treating it as one is how standing privilege enters an estate. We give every component its own identity, scope its credentials to the tools and data it genuinely needs, and keep the permission set narrow enough to read in a single page. Actions with real consequence, such as moving money, changing an account or sending something in your name, sit behind an approval step or a hard constraint in code rather than an instruction in a prompt. Permissions get reviewed as the system grows, because agent scope creeps quietly.
Data boundaries you can describe in one sentence
Security review turns on where data goes. We map every place your data crosses a line: into a model provider, into an index, into a log, into evaluation tooling. Then we make those crossings explicit choices rather than side effects, covering what is redacted before it leaves, what is retained, by whom and under which rule, which tenant or legal entity a record belongs to, and which deployment option keeps the whole path inside infrastructure you control. Your reviewers get a data flow they can check line by line against your own policy.
Audit trails and the evidence pack
When something goes wrong, the only question that matters is what the system did and why. Every consequential step carries a record: the input it acted on, the context it retrieved, the tool it called, the decision it reached and the person or policy that authorized it. That record is written for a reviewer, not for a debugger. The same discipline produces the evidence pack a security function asks for: architecture and data flow, the threat model, a control mapping against the framework you already report under, adversarial test results and the runbook your operators will use.
Why this matters most in financial services
Banks, insurers and payments firms carry the strictest version of every question above: model risk governance, records obligations, third-party review, and a supervisor who will eventually ask how a decision was reached. The founders built payments infrastructure in which every payment is bound to an auditable spend policy, a legal platform where each role sees only what that role allows and document custody is tracked throughout, and an attack-surface platform whose reporting aligns to SOC 2, ISO 27001, HIPAA and PCI-DSS. Those are our own ventures rather than client engagements, and the discipline inside them is what we bring to your build.
What you get
- A written threat model for your system: the assets it can reach, the untrusted inputs it reads, the actions it can take, and the control that bounds each one.
- An identity and permission design covering every agent, service and tool, with scoped credentials and named approval points for consequential actions.
- A data flow description naming every boundary your data crosses, what is redacted before it leaves, and what is retained under which rule.
- An audit trail specification, implemented in the running system, that lets a reviewer reconstruct any single decision after the fact.
- A control mapping against the framework you already report under, so your security team can review the work in their language rather than ours.
- Adversarial test cases, including prompt injection and tool misuse, carried in the evaluation suite that ships with the system.
Evidence
Redwipe is an attack-surface management platform we built and still run: continuous discovery and assessment of an organization's external attack surface, where verification has to prove real exposure without causing harm before anyone is asked to act on it.
Redwipe and the rest of what we have built →
What this is not
This is security engineering for the AI systems we design and build. It is not penetration testing, not a managed security operations center, not managed detection and response, and not a compliance certification service. We do not issue attestations or audit opinions, and we do not sign off on your controls. What we produce is the design, the implementation and the evidence your own security function, your auditors and your regulators can examine. Where an independent test or attestation is required, we say so and work alongside whoever you appoint.
Talk to a partner
Send us the system your security review is holding, and we will come back with the threat model, the control design and the evidence pack it needs.
