Know your agent: build a useful identity record

Updated 17 October 2026. “Know your agent” is a useful product question when it means more than giving software a name. The record should explain why the agent exists, what it may do and who owns its continued access.

Connect identity to purpose

An illustrative agent record can include the responsible owner, intended workflow, permitted tools and credential lifecycle. Keep the record tied to the deployed instance rather than a generic product category. Two agents using the same model can have very different authority.

Ownership should survive organisational change. If a person changes role or a project ends, the team needs to know what happens to the agent and its credentials. A permanent service account should not become the accidental memorial to a temporary experiment.

The registry does not enforce the boundary by itself. Connect it to the systems that grant, check and revoke access. Then test whether a change in the approved scope produces the expected change in behaviour.

Avoid treating the banking analogy as a legal equivalence. Agent identity controls and customer-identification obligations are different subjects. The useful shared idea is that consequential access should have an intelligible purpose and accountable ownership.

The practical next step

Pick one deployed agent and trace its access back to a current owner and purpose. If the record cannot explain why a permission exists, review it before adding another one.

Keep the resulting decision, its owner and unresolved questions in a short decision record. For claims about agent behaviour, connect the decision to evaluation evidence rather than relying on a successful demonstration alone.

Further primary reading: NIST AI Risk Management Framework. The review map and product recommendations above are my analysis, not a certification or a legal assessment of a particular deployment.