Lab idea / AI-enabled offense
Build an API authorization matrix from the spec and role policy
Use AI to draft coverage across endpoints, identities, and object ownership—then check the gaps in an isolated staging API.
Falsifiable hypothesis
Combining an API description with an explicit role-and-ownership policy can help an assistant identify missing authorization test combinations without inventing endpoints or permissions.
Source-led motivation
OpenAPI provides a machine-readable description of an HTTP API. Using that description together with a separate business authorization policy as input to an assistant is a proposed RedLatent workflow, not a claim that the specification proves authorization is enforced.
Authorized lab scope
An owned or approved staging API populated with synthetic tenants, users, and objects. Exclude destructive operations until explicitly approved.
What to try
- Provide a pinned OpenAPI document, the intended role policy, and a synthetic account/ownership table. Tell the assistant that undocumented business permissions are unknown, not inferred from endpoint names.
- Generate a matrix of operation, permitted role, object owner or tenant, expected decision, and supporting specification or policy reference. Include legitimate success cases as well as expected denials.
- Review the matrix for unsupported paths and wrong assumptions. Select a small read-only subset covering same-owner, different-owner, lower-role, and unauthenticated cases.
- Execute the reviewed cases using disposable credentials in staging, record actual decisions, and investigate mismatches against the intended policy. Retain the matrix for regression testing after fixes.
Prerequisites
- An accurate API description pinned to the deployed staging version.
- A separate business authorization policy and synthetic owner/non-owner accounts.
- An approved test harness and observability for application authorization decisions.
Comparison & control
Compare generated coverage to a manually prepared matrix. Verify the expected decisions with the application owner before scoring apparent authorization failures.
Observations to collect
- Test coverage by operation, role, tenant, and ownership condition.
- Expected and actual decisions with correlated request and application log IDs.
- Incorrect expectations caused by outdated specifications or missing policy context.
Disconfirming evidence
- The assistant fabricates permissions or adds no valid coverage beyond the manual matrix.
- The observed mismatch is a stale description or policy misunderstanding rather than an enforcement defect.
Stop conditions
- Stop at the approved target and data boundaries; do not send client artifacts to a model provider without approval.
- Stop before destructive operations or unexpected effects; reproduce only with disposable accounts and synthetic records.
Source bibliography
- OpenAPI Specification v3.2.1 ↗
OpenAPI Initiative / Linux Foundation
Publication date: Date not supplied · Editorial check 2026-10-26 UTC
What is the OpenAPI Specification? Official interface-description standard; not evidence of runtime authorization enforcement.