Authorization & tenant isolation
Can one user, role, or organization cross a boundary the application assumes is enforced? We test object, function, and tenant-level authorization—not just exposed endpoints.
Security for modern software
Do the rules actually hold?
Find where software allows more than it should.
RulesHold assesses the boundaries modern applications depend on: identity, authorization, APIs, tenant isolation, business logic, and AI behavior.
TRUST BOUNDARY MODELExamples
UserRoleTenant
APIDataAction
DocumentModelTool
Application flowBoundary under test
Security failures happen when an identity, tenant, data, or tool boundary can be crossed when it should not be.
Web applicationsAPIsMulti-tenant SaaSIdentity systemsAI applications
What we test
The security controls your product actually depends on.
A scanner can tell you a package is old. Application security has to answer whether a real user can cross a real boundary.
Authentication & identity
Login, recovery, MFA, sessions, tokens, invitations, role changes, and privilege transitions are assessed as connected identity workflows rather than isolated screens.
APIs & business logic
We look beyond signatures for behavior that becomes dangerous when valid application features are used in unexpected sequences, states, or combinations.
AI application boundaries
RAG, prompts, tenant context, tool permissions, sensitive output, and agent actions introduce trust boundaries that need application-level testing—not generic jailbreak lists.
Our standard
A finding should survive an engineer asking, “prove it.”
What is vulnerable?
How is it exploited?
What does an attacker gain?
Why does the vulnerability exist?
How can the team reproduce it safely?
What fixes the root cause?
Did the fix actually close the path?
Engagement model
Controlled, authorized, and built around evidence.
A request is the beginning of scoping—not permission to attack a system.
- 01
Request
Tell us what you operate and why you need the assessment. No credentials or sensitive access material.
- 02
Scope
We define targets, identities, roles, exclusions, timing, data handling, and stop conditions.
- 03
Authorize
Rules of Engagement and written authorization are completed before intrusive testing starts.
- 04
Assess
The application is tested against the agreed trust boundaries and attack surface.
- 05
Verify
Findings include evidence, root cause, remediation direction, and retesting after fixes.
Start with scope
Tell us what needs to be trusted.
Share the high-level application context and assessment goal. We’ll determine the right scope before any sensitive access details are exchanged.
Request assessment