KAP

Search the portfolio.

Quick links

↑ ↓ Navigate   Enter Open   Esc Close

02 / KAP · SECURITY ENGINEERING

Security is a
design responsibility.

The questions behind the interface: who can act, which data they can access, and what happens when inputs or expectations break.

CONTROL / 01

Authorization beyond sign-in.

RISK TO EXAMINE

A valid account attempts to access another organization’s record.

DESIGN RESPONSE

Keep organization context in API and data queries; validate ownership of linked records.

Tenant isolation & authorization
CONTROL / 02

Correctness under repeated actions.

RISK TO EXAMINE

A repeated payment or untrusted invoice total changes the financial record.

DESIGN RESPONSE

Define idempotency, validate fields, calculate authoritative totals, and review concurrent writes.

Financial integrity & household access
CONTROL / 03

Privacy at the field level.

RISK TO EXAMINE

A record is visible, but some of its fields should remain private.

DESIGN RESPONSE

Enforce audience rules and field visibility on the server; review sensitive record handling.

Audience rules & field privacy

TRACEABILITY / SOURCE REVIEW

Claims should have
a place to point.

Selected test definitions, reviewed November 6, 2026. These are source references, not live test results.

01

KapCore

apps/api/test/tenant-isolation.test.ts
SNAPSHOT
66c5f1ab575402

NestBudget

tests/finance.test.ts
SNAPSHOT
a67c022b5d4803

Kap Services

src/lib/invoice-model.test.ts
SNAPSHOT
9b83e5f1433904

Hatlangh Beh

src/features/privacy/visibility.test.ts
SNAPSHOT
177ebe623a45

Application test suites were not rerun. These examples do not represent a complete security audit or production certification.

AN ILLUSTRATIVE EXAMPLE

See the access
decision change.

Use the model to explore how identity, role, and resource ownership work together. The case studies describe the actual project evidence.

INTERACTIVE MODEL01 / ACCESS CONTROL

A valid account is
only the beginning.

Explore how role and ownership change an access decision.

Same organization

ROLE
Editor
USER SCOPE
Organization A
RESOURCE OWNER
Organization A
AuthenticatedPass
Role permits updatePass
Organization matchesPass

Allow the update

The role permits editing, and the resource belongs to the user’s organization.

Different organization

ROLE
Editor
USER SCOPE
Organization A
RESOURCE OWNER
Organization B
AuthenticatedPass
Role permits updatePass
Organization matchesDeny

Deny cross-organization access

An editing role does not grant access to another organization’s records.

Read-only role

ROLE
Viewer
USER SCOPE
Organization A
RESOURCE OWNER
Organization A
AuthenticatedPass
Role permits updateDeny
Organization matchesPass

Deny the update

Membership allows the record to be read; the viewer role does not permit changes.

Illustrative logic. No live requests or tests run.

Read the KapCore case study

REVIEW METHOD

Follow the unexpected path.

01 / MODEL

Find the boundary.

Identify the actors, resources, sensitive fields, and decisions that cross a trust boundary.

02 / CHALLENGE

Question the assumptions.

Try the wrong owner, a repeated action, an expired permission, or an invalid relationship.

03 / VERIFY

Connect it to evidence.

Read the implementation and tests, then define the additional checks needed for production.

LET’S CONNECT

Have a role or
project in mind?

I’d welcome a conversation about the work and where I can contribute.

Start a conversation