Skip to content
PhiloCyber logo
Client work / Anonymized

Proof, not promises.

Four engagements, anonymized by contract and by design. Details that could identify a client are stripped; what remains is the shape of the problem, the work and the outcome classes — so you can judge how I operate without anyone's confidentiality paying for it.

  1. C/01

    LLM application pentest, before it was a category

    Early mover · 2023

    See the serviceDiscuss your system

    Situation

    A public-facing LLM chatbot, weeks from launch, built to answer questions from institutional data. The team had tested quality and accuracy — nobody had tested it adversarially.

    Constraint & anonymization

    Anonymized by removing geography and institutional detail; the date (early 2023) is kept deliberately — it is the point of this study. This was one of the first offensive assessments of an LLM application, run about two years before most firms added “AI” to their pentest page.

    Approach

    1. 01Scoped written authorization and a non-production mirror of the chatbot before any testing
    2. 02Manual adversarial testing of the conversation layer: direct and indirect prompt injection, system-prompt extraction, data exfiltration through the model
    3. 03Every candidate finding reproduced twice and chained to its business impact before making the report

    Finding classes

    • Prompt injection paths that overrode the system instructions and repurposed the assistant
    • Sensitive information disclosure: the model could be steered into revealing data outside the intended scope
    • Missing output handling and rate controls that turned model misbehavior into user-facing risk

    Outcome classes

    • Launch proceeded on a fixed attack surface instead of an untested one
    • The findings became the organization's first concrete argument for a pre-launch AI review gate
    • Remediation validated on retest, with closure evidence the team could show stakeholders

  2. C/02

    Building an internal AI security capability, not a dependency

    Enablement program

    See the serviceDiscuss your system

    Situation

    An engineering organization shipping GenAI features with no in-house AI security expertise. Leadership's default plan was “hire internally eventually” — and ship untested until then.

    Constraint & anonymization

    Anonymized by removing industry and date. This study exists to answer one objection: “we'll build this capability ourselves.” Exactly — that is the product.

    Approach

    1. 01A workshop series built around the team's own architecture, not generic slides: their agents, their tools, their data flows
    2. 02A secure-development baseline for AI features: what to check before merge, what to escalate, what to never ship
    3. 03Hands-on labs where engineers attacked sanitized replicas of their own systems and read real findings

    Finding classes

    • The team's threat intuition was strong on classic AppSec and absent on model-layer abuse
    • No shared vocabulary for AI risk: “is this prompt injection thing real?” was an open debate
    • Review paths existed for code, none for prompts, tools or model behavior

    Outcome classes

    • The internal team now runs first-pass AI security review on its own features
    • Specialist time is reserved for what it is actually for: adversarial validation, not basic hygiene
    • The “hire vs. buy” question resolved into “build internally, validate externally” — the durable configuration

  3. C/03

    Multi-agent system and MCP assessment in production

    Flagship · agents + MCP

    See the serviceDiscuss your system

    Situation

    A production multi-agent system acting through MCP tool integrations: an orchestrator delegating to specialized agents, with tools that could read and act on real business data.

    Constraint & anonymization

    Anonymized by removing industry and date. Agentic systems are usually built in-house — no scanner has ever seen yours — so this study stays at the level of architecture classes and attack chains.

    Approach

    1. 01Threat modeling of the agent topology first: trust boundaries between orchestrator, agents, policy gates and MCP servers
    2. 02Adversarial testing of tool chains: what an agent could be steered into doing, with whose permissions, over whose data
    3. 03Identity and authorization review across the agent-to-tool boundary, where most real exposure lived

    Finding classes

    • Excessive agency: tool permissions broader than the agent's actual job, turning prompt manipulation into consequential actions
    • Indirect prompt injection through retrieved content crossing the trust boundary uninspected
    • Authorization gaps between the agent layer and the tool layer — each side assumed the other checked

    Outcome classes

    • Validated, chained exploit paths with business impact attached — not a list of theoretical findings
    • A remediation roadmap split into quick fixes and architectural changes, sized for the team that had to execute it
    • Retest-confirmed closure evidence usable in front of customers and auditors

  4. C/04

    AI security policy and governance from zero

    Governance build

    See the serviceDiscuss your system

    Situation

    A company already shipping GenAI features — and employees already using shadow AI — with no inventory, no ownership and no rules. The trigger was external: customers and auditors started asking questions nobody could answer.

    Constraint & anonymization

    Anonymized by removing industry. Governance work never sells as a cold program: it started with a paid diagnostic, and the client could have walked away with the roadmap. They stayed for the build.

    Approach

    1. 01Paid diagnostic first: questionnaire-driven scoring across governance dimensions, then targeted stakeholder interviews
    2. 02Policy architecture: AI inventory including shadow AI, acceptable-use and data-handling rules people would actually follow
    3. 03Review-path design: pre-launch security review for AI features, with evidence models mapped to the frameworks their customers cite

    Finding classes

    • AI usage far broader than leadership believed — the inventory was the first honest picture
    • Policies existed on paper in adjacent areas but nothing enforced or owned for AI
    • Vendor and third-party AI exposure with no questionnaire, no evidence, no owner

    Outcome classes

    • A working governance program with named owners — readiness, not certification theater
    • Customer and auditor questions now answered with evidence instead of apologies
    • A quarterly re-score cadence that makes posture movement visible to the executives who fund it

Your system could be the next one.

Every engagement runs under the same rules: written scope before access, named specialist end to end, anonymized-by-default evidence.

Tell me what you are building
Case Studies | PhiloCyber