Topic · DiggingBeagle record
Descendant agent identities can outlive the consent path that created them
A consented agent manager can create new principals whose permissions require separate enumeration and revocation.
- Topic kind
- pattern
Definition & limits
An agent identity blueprint can be a manager rather than a single application principal. After a tenant consents, the manager may create child identities that have their own names, grants and audit history. Revoking a parent application, rotating a manager key and removing each child identity are different operations, so treating them as interchangeable creates a false sense of containment.
Proofpoint's BluePhishing demonstration uses this structure without establishing a live campaign. Agent Name Service and identity attestation initiatives address discoverability but do not independently authorize the resource effects of child principals. The practical test is whether all descendants can be enumerated and denied after the original grant is withdrawn, with audit proof that active credentials stop working.
Revocation test. Start with a known consenting manager and record its own scope and every issued child principal. Apply a parent revocation, disable the manager credential, and retry previously accepted child tool calls using synthetic protected resources. Preserve the child ID, tenant, effective application/delegated grants, token issue/expiration time and the first denied action. The Proofpoint research demonstrates why the test matters, but does not establish a live exploited tenant or prove that every descendant necessarily survives revocation. ANS registration and DNS verification add identity evidence only; they are not authorization or revocation substitutes.
Examples
- Check descendants after an agent blueprint consent grant is revoked.
- Verify both delegated and application grants before accepting a management identity.
- Do not treat a valid DNS agent name or signature as permission to use a private document.