Authorized security testing, scoped in writing.

Five areas, one adversary's view.

The same principal who designs and builds production systems tests them the way an attacker would. Each area can be scoped on its own or combined into a single objective-based engagement.

• T1
  Application and API penetration testing

  Web applications, REST and GraphQL APIs, authentication and session handling, authorization logic (broken access control, tenant isolation), input handling, and business-logic abuse. Manual testing first, tooling to cover breadth.

• T2
  Cloud and infrastructure assessment

  The externally reachable attack surface plus cloud configuration review across AWS, GCP and Cloudflare: identity and permissions, exposed services, secrets handling, and network segmentation.

• T3
  Red team exercises

  Objective-based, time-boxed engagements against a defined target, run inside agreed rules of engagement. The goal is the realistic path to the objective, documented step by step, handed over as a full attack narrative with the fixes that would have stopped it.

• T4
  Embedded and connected-device security

  Firmware and update-path analysis, device-to-cloud trust, companion mobile apps, and wireless interfaces for IoT and wearable products. This builds on the studio's hardware and firmware practice.

• T5
  AI and LLM-agent security testing

  Prompt-injection and data-exfiltration paths, tool-permission abuse, agent sandboxing and containment, and the supply chain around model-connected systems. This builds on the studio's AI workflow practice.

What we will and won't do.

Offensive work is only useful when the client can trust how it is run. These rules apply to every engagement and are restated in the scope memo.

• R1
  Authorization comes first

  Before any traffic is sent, we hold a signed authorization from someone with the authority to grant it: named targets, a testing window, source addresses, and emergency contacts on both sides.

• R2
  Scoped and bounded

  Testing stays inside the agreed scope. No denial-of-service, no destructive payloads or ransomware, no mass targeting, and no pivoting into third-party systems. Production-safe by default; anything riskier has to be written into the scope and agreed in advance.

• R3
  Minimum necessary access

  We touch only what is needed to prove impact. Evidence is redacted and stored encrypted, and retention and deletion terms are set in the scope memo. Where AI tooling is used, client data is processed only where the engagement terms allow it.

• R4
  Stop conditions and fast escalation

  Critical findings are reported as soon as they are confirmed, not held for the final report. Testing pauses on any sign of unintended impact.

Findings you can act on.

• D1
  The report

  An executive summary for decision-makers, then each finding with severity, reproduction steps, evidence, and specific remediation guidance. Red team engagements add the full attack narrative from first foothold to objective.

• D2
  The debrief

  A working session with your engineering team to walk through the findings, answer questions, and agree on fix priority.

• D3
  The retest

  A time-boxed retest of fixed findings inside an agreed window, so the report closes with verified fixes rather than promises.

Found something in our systems?

Report vulnerabilities in LaFayette Labs systems to phil@lafayettelabs.com. Our security.txt lists the same contact. Please give us a reasonable chance to fix an issue before any public disclosure.

The same principle runs the other way. A vulnerability found outside a paid engagement goes to the affected vendor through its disclosure channel before anything is published.