# PENTECTON - Full Reference

> A senior security architect working inside engineering teams on the security of what they ship: architecture reviews before a feature is built, threat models before release, and concrete fixes. Also covers AI/LLM feature security.

## About

PENTECTON works inside engineering teams on the security of what they're shipping: reviewing architecture before a feature is built, threat-modeling it before release, and turning risks into concrete fixes. Founded by Radoslaw Karpowicz, a security architect with experience at Auth0, Okta and Snowflake. OSCP certified, published security researcher and 0-day discoverer.

## Services

### SaaS Security Readiness Review

You receive an architecture-level risk map, prioritized systemic findings, and a 30-60-90 day remediation plan focused on the risks that can affect enterprise sales, audits, and long-term product security.

- Audience: CTOs, VP Engineering and platform leaders
- Typical engagement: 5-10 days
- URL: https://pentecton.com/services/security-architecture-review/

**What does a SaaS Security Readiness Review cover?**
System architecture, data flows, threat modeling, API security, authentication and authorization design, integration security, and infrastructure security design - the structural areas where systemic risk accumulates.

**What do I get at the end?**
An architecture risk map, a trust boundary and data flow review, a systemic risk register, an architecture improvement plan, a 30/60/90 day remediation roadmap, and an executive summary for the CTO or founder.

**How long does it take?**
Typically 5 to 10 days, depending on system complexity.

**When should we engage?**
Before scaling the platform, before onboarding enterprise customers, before a security audit, or when introducing major integrations or identity changes.

### Product Security Assessment

You receive a prioritized product security report, buyer readiness notes, and a remediation backlog to help your team fix key issues before enterprise customers, auditors, or security reviewers ask difficult questions.

- Audience: CTOs, engineering leads and product teams
- Typical engagement: 5-7 days
- URL: https://pentecton.com/services/product-security-assessment/

**What does a Product Security Assessment cover?**
Attack surface analysis, architecture security review, evaluation of security controls, authentication and authorization review, API exposure analysis, and dependency and integration review.

**What do I get at the end?**
A prioritized risk register, enterprise buyer readiness notes, security questionnaire support notes, a quick-wins and remediation backlog, and an executive summary for leadership.

**How long does it take?**
Typically 5 to 7 days, depending on system size.

**When should we engage?**
Before a security audit, before onboarding enterprise customers, or when multiple risks exist but priorities are unclear.

### AI Security Architecture Review

You receive a focused AI security review covering data flows, prompt injection, model access control, tenant isolation, provider risks, and practical recommendations before AI features reach customers at scale.

- Audience: CTOs, AI leads and engineering leaders
- Typical engagement: 5-8 days
- URL: https://pentecton.com/services/ai-security-review/

**What does an AI Security Architecture Review cover?**
AI architecture analysis, model integration review, prompt injection risk analysis, data leakage scenarios, model access control, API security review, and AI abuse scenarios.

**What do I get at the end?**
An AI data flow and trust boundary map, a prompt injection and data leakage risk review, model and LLM provider risk notes, an AI access control and tenant isolation review, control recommendations, and an AI risk summary for the CTO or product team.

**How long does it take?**
Typically 5 to 8 days, depending on system complexity.

**When should we engage?**
Before launching AI features into production, when integrating LLM APIs or building RAG workflows, or when sensitive data may enter AI prompts or context.

## Guides

### Security Architecture Review Guide for SaaS Platforms

What a security architecture review involves, when it makes sense, and what engineering teams should expect from the process. Written for CTOs and engineering leaders building or scaling SaaS platforms.

- URL: https://pentecton.com/guides/security-architecture-review-guide/

### OAuth/OIDC Pre-Launch Checklist

60+ product security checks for teams shipping SSO, OAuth 2.0/2.1, or OpenID Connect - aligned with the OAuth 2.1 draft. Free checklist from Pentecton.

- Audience: SaaS teams adding SSO; Backend engineers reviewing OAuth/OIDC; CTOs and security leads preparing for enterprise buyers
- URL: https://pentecton.com/guides/oauth-checklist/

OAuth is rarely broken by the spec. It is broken by small product and architecture decisions: the wrong flow chosen for the wrong client, redirect handling that grew permissive over years, token validation that quietly skipped a step.

This is an opinionated hardening companion to RFCs 6749, 7636, 7662, 8252, 9207 and 9700 - some lines are deliberately stricter than the spec requires, to close failure modes we see in real reviews.

Much of that strictness simply tracks where the spec is going. OAuth 2.1 (the IETF draft draft-ietf-oauth-v2-1) folds OAuth 2.0, PKCE and the Security BCP into one document: PKCE mandatory for every client, exact redirect-URI matching, no bearer tokens in query strings, and the Implicit and Password grants removed. Where a check here looks stricter than the OAuth 2.0 you know, it is usually already the 2.1 default.

Compliance documents tell you what to write down; this is the other kind: what to verify on the request path.

**01 OAuth ≠ authentication**
An access token is an authorization credential, not a login assertion for the relying app. If your application needs to know who the user is, use OpenID Connect on top of OAuth and validate the security-relevant ID token claims required for the flow.

_Flow and layering_
- No code path uses a raw access token as a login assertion for the client application. If the app needs to know who the user is, it uses OIDC and reads identity from a validated ID token.
- The login flow obtains an ID token. The UserInfo endpoint may be called with an access token for additional claims, but session identity is anchored to validated ID token claims, not to UserInfo output alone. If UserInfo is used, its sub claim must exactly match the validated ID token's sub.
- The user's stable internal ID is the tuple (iss, sub), never sub alone (only unique within an issuer), and never email or preferred_username (mutable and attacker-influenceable).

_ID token claim validation_
- The iss claim is compared exact-match against the expected issuer URL. Not startsWith, not a regex.
- The aud claim contains this application's registered client ID. If aud has multiple values, the token is rejected unless the additional audiences are explicitly trusted. If azp is present, it equals this client ID unless the integration has a documented reason otherwise.
- The exp claim is enforced with a tight clock-skew window (at most 120 seconds); iat is used for freshness, and tokens older than a reasonable bound are rejected even if not expired.
- If a nonce was sent on the authorization request, the nonce claim on the ID token is verified against the session-bound value and consumed, never accepted twice.

_Signature verification_
- Every ID token signature is verified against the IdP's JWKS. The expected algorithm is pinned (typically RS256 or ES256) and never accepted from the token header. The none algorithm is rejected.
- JWKS is refreshed on signature-verification failure to handle key rotation, rate-limited to prevent denial of service against the IdP. A missing or unknown kid fails closed and never falls back to unverified.

**02 PKCE and public client safety**
Single-page apps and mobile clients cannot keep a secret. Without PKCE, an intercepted authorization code is a free pass. Implicit Flow is deprecated; do not ship it.
Covers: Authorization Code Flow, S256, and the death of Implicit.

**03 Redirect URI handling**
Most major OAuth account-takeover writeups in the last five years start the same way: a redirect URI that matched more than it should have. Exact-match allowlists close the entire category.
Covers: Exact allowlists, callback hygiene, native apps.

**04 State, nonce and mix-up defense**
The state parameter is the OAuth flow's CSRF token. Without it, or with one that is reusable or unbound from the session, an attacker can stitch their own authorization code into your user's session.
Covers: CSRF, replay, and IdP confusion.

**05 API token trust**
An access token is untrusted input until your API validates issuer, audience, expiry, scope, tenant context, and token integrity. JWT and opaque tokens validate differently; both must be validated.
Covers: JWT vs opaque, claim validation, object-level authorization.

**06 Refresh tokens and session lifecycle**
The hidden sixth mistake. Refresh tokens live longer, fail more silently, and rarely get the same scrutiny as access tokens. They are also the easiest path to a persistent session takeover.
Covers: Rotation, family revocation, session hygiene.

**07 Federation and client hardening**
The lines outside the obvious flow that quietly determine whether your federation can be subverted. Discovery, client authentication, and account linking are where mature implementations still grow real findings.
Covers: Discovery, client auth, account linking, logging.

## 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.

## Research

- [How I discovered a vulnerability in hundreds of Mac OS X applications](https://vulnsec.com/2016/osx-apps-vulnerabilities/) - 0-day / Vulnerability research: Identified a critical vulnerability in the Sparkle Updater framework that allowed remote code execution through man-in-the-middle attacks on applications using unencrypted HTTP connections. Hundreds of macOS apps were affected, including VLC, iTerm and Adium.
- [How to detect the Sparkle Updater vulnerability](https://vulnsec.com/2016/detecting-osx-apps-rce/) - Vulnerability research: Detection techniques and proof-of-concept exploitation of the Sparkle update framework vulnerability using mitmproxy. Demonstrates automated identification of vulnerable applications through network traffic analysis.
- [How attackers exploit routers remotely](https://vulnsec.com/2016/how-routers-are-exploited-remotely/) - Network security: Research into a remote code execution vulnerability in Netgear routers allowing unauthenticated command execution as root. Demonstrates browser-based exploitation through DNS rebinding techniques to compromise home networks.
- [Solving the XSS challenge from Intigriti](https://vulnsec.com/2019/intigriti-xss-challenge/) - Offensive security: Demonstrates a race condition vulnerability in a domain whitelist bypass challenge. By dynamically changing an iframe's location hash before a redirect executes, arbitrary JavaScript execution is achieved within the target domain's context.
- [picoCTF 2019 - JavaScript Kiddie writeup](https://vulnsec.com/2019/picoctf-2019-js-kiddie/) - Offensive security: Technical writeup of two picoCTF web challenges involving PNG file format analysis and cryptographic key recovery. Published in Paged Out! magazine issue #2.
- [SANS Holiday Hack Challenge - Honorable Mention](https://vulnsec.com/2017/SANS-Holiday-Hack-Challenge-2016/) - Reverse engineering: Awarded honorable mention in the SANS Holiday Hack Challenge. Covers Android APK reverse engineering, ELF binary analysis, SQL injection, privilege escalation, cryptanalysis and Meteor framework exploitation across interconnected targets.

## Contact

- Website: https://pentecton.com/contact/