General:

1. I think the "byte[]" type needs to be more fully described, as it appears that this document is the only one in the set of SSH specifications that use it (RFC 4251 defines "byte[n]", where "n" is a fixed length, but not "byte[]"). I believe it represents a sequence of bytes whose length is implicitly defined by context as opposed to having an explicit length prefix (like the "string" type), but this is not immediately clear.
2. Are messages that have a "constraint[]" field (such as "SSH_AGENTC_ADD_ID_CONSTRAINED") containing 0 elements (i.e., empty constraints) valid? I assume not since there is a different message number for unconstrained operations, but I think the doc should be clear on this.
3. In section 3.2.7.3, a reference to section 6 of RFC 4251 (which explicitly defines when to use "@" in identifiers) is likely more useful to the reader than a reference to section 4.2 of RFC 4251.
4. Observation #3 above applies to section 3.8 as well.
5. In section 5.1, "Clients MAY opportunistically attempt..." should be "SSH clients MAY opportunistically attempt...".
6. Section 5.2 says: "As mentioned previously, many deployed implementations only support the former, pre-standardisation "auth-agent-req@openssh.com" request name. The latter "agent-req" name SHOULD only be used if support was explicitly advertised as per Section 5.1.". But the example says: ""agent-req" or "auth-agent-req@openssh.com"". Either the "former" and "latter" need to be switched, or the example ordering switched.
7. Likewise in section 5.3, "As above, the latter "agent-connect" open type name..." should be changed to "As above, the former "agent-connect" open type name...".

Security-specific:

1. Section 4 explicitly calls out the use of UNIX domain sockets and Windows Named Pipes with a reference to Section 8. However, I did not see any specific text regarding these in section 8. I expected some mention of using file permissions (for UDS) and security descriptors (Windows Named Pipes) or other mechanisms to control access.
2. Section 8 says: "SSH implementations SHOULD NOT forward use of an agent by default and MAY implement additional controls over key visibility and use for forwarded agent connections.". Strengthening the MAY to a SHOULD seems like a good idea here.
3. Section 8 says: "...SHOULD ensure that loaded token library code cannot gain access to other keys loaded in the agent". How can this be ensured? If I'm understanding the previous sentence correctly ("Loading a shared library on most platforms implies automatic execution of code in that library in the address space of the process that loads it."), it is common practice that the shared library for the token "driver" is loaded directly into the agent process. At which point, the library has unfettered access to the process's memory and can perform arbitrary operations. If the implicit suggestion is to use a sandboxed sub-process to load the library and interact with the token, then the text should be explicit on this point.
4. Section 8 says: "Finally, with respect to the agent locking functionality in Section 3.7, an agent SHOULD take countermeasures against brute-force guessing attacks against the pass-phrase". It would be helpful to the reader if an illustrative example of a countermeasure (such as lockouts, etc.) were mentioned, perhaps with a reference to a document providing guidance on how to implement such countermeasures.