An offensive perspective. A practical response. We examine how applications, identities and infrastructure can fail — and help technical teams build more resilient systems.
A specialist security practice for founders, security leads and engineering teams. Start with a consequential question about a system you own or are authorized to assess — not an unbounded promise to find everything.
Written authorization. Agreed assets and methods. Explicit stop conditions. Each engagement states what will be tested, what evidence will be retained and what remains outside the review.
A convincing report is useful only if a team can understand the consequence, make an informed change and verify the result. The investigation and the engineering response belong in the same conversation.
Connected decisions. Clearly defined boundaries. Conceptual illustration.
01
Scope
Define the assets, authorization, constraints and stop conditions before touching a system.
A written boundary for the work.
02
Investigate
Follow the highest-value questions. Validate behavior with controlled tests and the minimum necessary evidence.
Findings with context, impact and limitations.
03
Engineer
Work through the fix with your team. Connect a finding to an understandable implementation change.
A prioritized, reviewable remediation plan.
04
Verify
Retest agreed changes and document what was covered, what remains and who owns the next step.
Start before an engagement. Review pasted browser policies, prepare a testing scope or map a trust decision. These tools work locally in your browser; they do not scan targets or turn incomplete inputs into a security score.
No sign-up or upload. Inputs stay in browser memory and disappear on reload. Do not paste credentials or confidential records. A worksheet is a starting point, not an assessment of your system.
04 / QUESTION THE ASSUMPTION
A clearer question. A stronger boundary.
Security decisions become more useful when the claim is specific. Our technical guides separate definitions, evidence, limitations and practical verification — with primary sources and clearly labelled examples.
No. Authentication establishes an identity; authorization decides whether that identity may perform a particular action on a particular resource. Tenant boundaries, object ownership and background jobs still need explicit permission decisions.
Not necessarily. Removing a browser cookie is different from invalidating server-side authority. Other sessions, cached decisions, live connections and queued work may have separate lifecycles. Verify the protected actions your revocation policy is intended to stop.
No. Separate browser state can prevent workflows from sharing cookies or local storage. It does not conceal network activity, establish a complete operating-system boundary or replace application access controls. Define which state must remain separate, then test that boundary.
A prompt can express intended behavior, but it is not a dependable resource-authorization boundary. Validate tool permissions outside the model, distinguish untrusted content from instructions and inspect actual state changes rather than relying on the final answer.
Bring the difficult question. We’ll define a clear boundary.
A planned release, an uncertain permission model or a workflow that needs stronger control. Bring the system context, the accountable owner and the question you need to resolve. We’ll discuss a realistic scope before any testing starts.
