Overview
This case study examined the lifecycle behavior of an existing AI session capability after the researcher-owned parent object was deleted through the product's normal user interface.
The goal was to document what the endpoint did after deletion—not to treat a successful response as proof of a vulnerability.
Research question
Does a previously issued AI session capability continue to return structured context after its parent object is deleted, and can that behavior be distinguished from an invalid-session response?
Methodology
- Establish a successful baseline with the researcher-owned object.
- Delete the parent object through the normal interface.
- Repeat the endpoint request with the existing session capability.
- Use an invalid session sentinel as a matched negative control.
- Reproduce the post-delete behavior a second time.
- Separate observed technical behavior from an authorization claim.
Evidence
Observation
Runtime validation showed that the old session capability continued to receive a response without a cookie after the parent object was deleted. The endpoint still returned structured context in the tested post-delete state.
Finding status
The test established a technical lifecycle behavior. It did not establish unintended acquisition of the capability by an external party or prove that product semantics required deletion to revoke the capability.
Limitations
- External capability acquisition was not demonstrated.
- Product-level revocation semantics were not established.
- No third-party data or account was accessed.
- No accepted vulnerability or bounty is claimed for this case.
Lessons learned
A live post-delete capability is an operational primitive, but it is not automatically an authorization failure. A confirmed claim still depends on provenance, intended revocation semantics, boundary crossing, and concrete impact.