A senior security architect for your engineering team
Expert eyes on the security of what you design and ship
PENTECTON works inside your engineering team on the security of what you're shipping: reviewing architecture before a feature is built, threat-modeling it before release, and turning risks into concrete fixes.
A free 30-minute intro call with the architect who does the work. You describe what you're shipping; you leave with an initial read on where the risk sits.
Where I built security over 17 years as full time security engineer
You're probably here because
- You're designing a new feature and want expert eyes before you build
- Your architecture grew without a clear security model
- You don't have a dedicated security team to lean on
- You want security review as part of how you ship, not a tool to install
The Problem
The riskiest security decisions get made before a line of code is tested
New features, AI capabilities, APIs, and distributed systems introduce security risk at the design stage, long before a penetration test or a security review would ever catch it.
The systemic problems start in the architecture: authorization models, trust boundaries, service-to-service communication, tenant isolation, and integration patterns. By the time they surface in testing, they are expensive to unwind.
Bringing a security architect in while you are designing and shipping means catching these as design questions, not production incidents, and walking away with concrete fixes rather than a list of findings.
Background
The architect behind PENTECTON
PENTECTON is the practice of Radoslaw Karpowicz, a senior security architect with 17+ years across backend engineering, offensive security, and product security. He was the first security engineer at Auth0, grew into a Principal role over six years and through the Okta acquisition, and worked on threat models and identity security with engineering teams at Snowflake. He is OSCP certified and a published vulnerability researcher, including 0-days in the Sparkle update framework that exposed hundreds of macOS applications. Every engagement is his work: he reviews the architecture, threat-models the release, and walks your engineers through the fixes. No handoff to a junior team.
More on the backgroundWho this is for
Engineering teams of roughly 10 to 150 people, usually without a dedicated security function - typically:
- SaaS platforms
- AI startups building LLM-based products
- B2B platforms with complex integrations
- API-first companies
- Developer tooling companies
Sound Familiar?
When companies typically reach out
This is usually the point where a scan or a checklist is not enough, and someone needs to look hard at the design of what you are building and shipping.
- You're adding AI features and aren't sure what new risks they introduce
- Your platform has scaled and the security model hasn't kept up
- A release is coming and you want it threat-modeled before it ships
- An enterprise customer's security team is asking architecture questions you can't answer cleanly
- A penetration test surfaced deeper architectural issues you weren't expecting
- You just patched something ugly and want to know whether the same design weakness exists elsewhere
- Security keeps landing late and you want it handled earlier, while you design
Process
How engagements work
Most reviews run 5 to 10 working days.
Intro call
A free 30-minute call about what you're building and whether a review would help. No prep needed.
System understanding
A working session with your engineers on architecture, data flows, and integrations. A few hours of their time, not weeks.
Security assessment
The design is reviewed and threat-modeled: trust boundaries, authorization, tenant isolation, integration risk.
Report and fixes
A written report: prioritized findings, concrete design changes, and a remediation plan your engineers can act on without ongoing help.
Typical situations
What an engagement looks like
Securing a new feature before launch
The situation
A team was about to ship a major feature that changed how customer data moved between services, and wanted the design reviewed before it went out, not after.
What gets reviewed
The feature's data flows, new trust boundaries, authorization changes, and how it interacted with existing tenant isolation.
What you walk away with
A threat model of the feature and a short list of concrete design changes, fixed before release.
Threat-modeling an AI feature before it shipped
The situation
LLM features were being added to a product handling sensitive data. Strong ML team, but no one had mapped the AI-specific trust boundaries or data-exposure paths.
What gets reviewed
Prompt and response data flows, model access control, abuse scenarios, and adversarial input handling.
What you walk away with
An AI-specific threat model and prioritized design changes on the highest-risk data flows.
A security architect inside a fast-scaling platform
The situation
A platform had grown quickly and its security model lagged the architecture. Auth and trust boundaries were spread across services in ways the team found hard to reason about.
What gets reviewed
Authentication and authorization flows, trust boundaries, tenant isolation, and the assumptions behind key integrations.
What you walk away with
A clear map of the architectural weak points and a prioritized plan of concrete fixes.
If this sounds familiar, let's talk about what you're shipping.
Talk to a security architectResearch
Security research
Published vulnerability research, including 0-day vulnerabilities in the Sparkle update framework that exposed hundreds of macOS applications to remote code execution, and unauthenticated remote code execution in Netgear routers. All of it is public. The same attacker's view shapes every architecture review.
View researchFAQ
Frequently asked questions
What does a security architecture review involve?
Working directly with your engineers to examine how a system or feature is designed: trust boundaries, authorization models, data flows, integrations, and tenant isolation. You walk away with a prioritized set of concrete fixes, caught at the design stage instead of in production or a customer's security review.
Who runs PENTECTON?
PENTECTON is led by Radoslaw Karpowicz - first security engineer at Auth0, Principal through the Okta acquisition, product security work at Snowflake. He is OSCP certified and a published vulnerability researcher: his Sparkle update framework 0-days exposed hundreds of macOS applications to remote code execution. The research is public, and he personally does every engagement.
When should I bring in a security architect?
Two moments work best: when you're designing a new feature, so the architecture is reviewed before it's built, and just before a release, to threat-model it while fixes are still cheap. The further along a design is, the more expensive the changes, so earlier is better.
How much does a security review cost?
Most focused reviews take 5 to 10 working days. Each engagement is quoted as a fixed fee per system after a short intro call. The fee depends on the number of systems and integrations, the architecture's complexity, and whether AI features are in scope. Ongoing advisory is priced separately as a monthly arrangement.
How is this different from a penetration test?
A penetration test looks for exploitable bugs in a running system. An architecture review looks for structural weaknesses in how the system is designed: weak trust boundaries, unclear authorization models, risky integrations. A pentest finds the open window; an architecture review asks why the wall was built there. Both matter, and they answer different questions.
Is this a fractional CISO?
No. A fractional CISO runs your security program: policies, compliance, vendor questionnaires, hiring. PENTECTON works one layer down, at the technical design: reviewing architecture, threat-modeling features, and turning risks into concrete fixes your engineers act on. Teams with a CISO bring PENTECTON in for the deep technical review; teams without one get the part of security that actually touches what they ship.
What happens after the review?
You get a prioritized findings report and a clear remediation plan written for both engineers and leadership. From there, PENTECTON can stay involved to review fixes, threat-model the next feature, or advise as the architecture evolves. The report is written so your team can act on it without ongoing help.
Get expert eyes on what you ship next
A 30-minute call is enough to walk through your system, point at the highest-risk areas, and decide whether a focused review would help. You talk directly to the architect who would do the work. If a review is not the right next step for your system, you'll hear that on the call.
Talk to a security architect