While reviewing the ANP ecosystem, one thing that stood out is that ANP has strong identity and encryption mechanisms, but several important security properties appear to be left to SDK or deployment-specific behavior rather than being clearly framed at the protocol level.
This issue is not an exploit report. It is a request for spec-level clarification and guidance around who is responsible for several important security controls.
Motivation
For interoperable agent systems, authentication and encryption are necessary, but not always sufficient. In practice, deployers and SDK authors also need clear guidance for:
- whether authenticated operations require explicit authorization / consent
- what security events should be observable for auditing
- how credential invalidation should work after session termination
- what replay-protection guarantees are expected across restart / multi-instance deployments
Without protocol-level guidance, these responsibilities can become ambiguous across spec, SDK, and application layers.
1. Consent / authorization boundary
The protocol has strong agent authentication, but it would help to clarify whether the protocol expects:
- authentication only, with authorization entirely application-defined, or
- a recommended authorization / consent model for sensitive operations
Suggested clarification:
- state explicitly that authentication does not imply blanket authorization for all exposed operations
- recommend an application-visible authorization / consent decision point before action execution
- identify categories of operations where explicit approval is recommended
2. Auditability expectations
It would be useful for the protocol to say what security-relevant events implementations should expose or log.
Suggested clarification:
- define a minimal set of auditable security events, such as:
- auth success/failure
- token issuance / expiry / rejection
- session start / close
- replay / nonce rejection
- clarify whether these are protocol recommendations, SDK requirements, or deployment responsibilities
This would improve operational consistency across implementations.
3. Credential revocation semantics
It would help to clarify whether session termination is expected to invalidate previously issued credentials immediately, or whether token validity is intended to be purely TTL-based.
Suggested clarification:
- specify whether issued credentials should remain valid after session close
- recommend revocation semantics for bearer tokens or equivalent session-bound credentials
- clarify whether revocation is mandatory, optional, or deployment-dependent
This is especially important when sessions and credentials have different lifetimes.
4. Replay-protection scope
The protocol would benefit from clearer guidance on the intended replay guarantees.
Suggested clarification:
- is replay protection expected only within a live process / live session?
- should protection survive restart?
- should multi-instance deployments share replay state?
- which replay assumptions are acceptable for conforming implementations?
Even if the answer is "implementation-defined," making that explicit would help deployers understand the trust assumptions.
Proposed outcome
A short security considerations section, or additional normative/non-normative guidance, covering:
- authentication vs authorization
- required / recommended audit events
- revocation expectations for issued credentials
- replay-protection assumptions and deployment caveats
That would make the protocol easier to implement consistently and would reduce ambiguity about which layer is responsible for these controls.
While reviewing the ANP ecosystem, one thing that stood out is that ANP has strong identity and encryption mechanisms, but several important security properties appear to be left to SDK or deployment-specific behavior rather than being clearly framed at the protocol level.
This issue is not an exploit report. It is a request for spec-level clarification and guidance around who is responsible for several important security controls.
Motivation
For interoperable agent systems, authentication and encryption are necessary, but not always sufficient. In practice, deployers and SDK authors also need clear guidance for:
Without protocol-level guidance, these responsibilities can become ambiguous across spec, SDK, and application layers.
1. Consent / authorization boundary
The protocol has strong agent authentication, but it would help to clarify whether the protocol expects:
Suggested clarification:
2. Auditability expectations
It would be useful for the protocol to say what security-relevant events implementations should expose or log.
Suggested clarification:
This would improve operational consistency across implementations.
3. Credential revocation semantics
It would help to clarify whether session termination is expected to invalidate previously issued credentials immediately, or whether token validity is intended to be purely TTL-based.
Suggested clarification:
This is especially important when sessions and credentials have different lifetimes.
4. Replay-protection scope
The protocol would benefit from clearer guidance on the intended replay guarantees.
Suggested clarification:
Even if the answer is "implementation-defined," making that explicit would help deployers understand the trust assumptions.
Proposed outcome
A short security considerations section, or additional normative/non-normative guidance, covering:
That would make the protocol easier to implement consistently and would reduce ambiguity about which layer is responsible for these controls.