Knowing who the agent is solves half the problem. The other half is what it can do. These are separate concerns. Conflating them is a design error that shows up in almost every first-generation agent system.
Identity governs what data an agent can see. The action layer governs what the agent can do with it. An agent authenticated as a service account with broad read access can still be prohibited from sending messages, executing code, or writing records. Designing these constraints separately gives you two independent control surfaces — and two independent audit trails.
Most agent frameworks make this easy to ignore. A single line of configuration attaches any tool to any agent. That convenience is a trap. A document review agent that also holds a send_email tool is an agent that can exfiltrate data under the right prompt conditions.