Offensive testing needs hard boundaries.
AISEC requires authorization before it tests, keeps project data inside the owning tenant, and records the actions that change scope or security state. The interface explains the boundary; backend policy enforces it.
Backend policy is authoritative
The boundary is part of the product.
Target control
A project must prove control of its root or carry explicit authorization before assessment. Scope checks happen again when a scan starts.
Deny until authorizedTenant access
Account and project identity are checked at API boundaries for projects, scans, findings, integrations, membership, and Sentinel data.
Project data is not globally addressableOwnership
Account ownership is distinct from an ordinary role. Transfers and owner changes protect against removing the final owner or locking the account out.
At least one owner remainsPermissions
Built-in roles and project permissions map to real product actions. Hiding a frontend control is not treated as authorization.
Backend enforcement is authoritativeDemo boundary
Controlled demo fixtures remain inspectable without becoming writable customer state.
Demo mutations are rejectedDifferent surfaces need different controls.
Scans
Start, cancel, retry, and retest actions are checked against the current account, project, plan, scope, and permission state.
A stale page cannot grant a permission the API no longer allows.
Findings & evidence
Issue details, evidence, exports, and remediation state follow project access and plan controls.
Restricted evidence is not unlocked by direct URL navigation.
Repositories
The GitHub App installation and the project link define which repositories can provide context. Repository status and analyzed commit remain visible.
Removing access breaks the link instead of silently using old authority.
Integration secrets
Webhook secrets are encrypted at rest and shown in plaintext only when created or rotated.
Subsequent reads expose state, not the stored secret.
Sentinel response
L7 uses eligible evidence from the current project. Synthetic test addresses, global correlation, and other tenants are excluded from the customer blocklist.
A WAF action is shown as effective only after provider confirmation.
Changes that alter authority should leave a record.
Recorded security state
- 01Membership, invite, role, permission, and ownership changes.
- 02Project, integration, API key, and scan lifecycle actions.
- 03Finding workflow and retest history.
- 04Sentinel canary, token, layer, and WAF changes.
What a client can verify
- 01Who currently has access and what role they hold.
- 02Which target and repository are attached to the project.
- 03What produced a scan or issue and when it changed.
- 04Whether a response control is configured, pending, or provider-confirmed.
Evidence support is not certification.
AISEC maps findings to frameworks such as OWASP, CWE, PCI DSS, ISO 27001, and SOC 2 criteria to support remediation and audit work. That mapping does not certify an organization or replace an auditor.
We can show
Scope, tool output, reproduction evidence, issue history, retest outcome, and framework mappings.
Technical evidenceWe do not claim
That a scan alone proves complete security, guarantees no vulnerabilities remain, or grants a compliance certification.
No absolute assuranceWe disclose
Partial and planned capabilities as such, including Sentinel layers that are not fully implemented.
Built state over marketing stateNeed a control answered directly?
Send the exact requirement, deployment context, and evidence format your team needs. We will answer with the current product state.