Microsoft AGT: agent as the principal
AGT's policy schema keys decisions on agent_id, tool, and action.type. The README is explicit: "AGT enforces governance at the application middleware layer, not at the OS kernel level. The policy engine and agents share the same process boundary." There is no user_id in the schema, no on-behalf-of (OBO) flow, and no capability attenuation. End-user identity, if you need it, has to be layered on outside, typically via Microsoft Entra and OAuth OBO (sub + act.sub claims).
Hexgate: the user travels with the call
Hexgate threads end-user identity through every decision. A per-request User context manager carries user_id, role, and session_idas a signed Biscuit token; role policies decide what that role can do. Identity is resolved at call time from a contextvar, so the same wrapped agent serves many users concurrently, with different effective permissions, without seeing each other's policies. Biscuit's caveat system lets you narrow rights at request time, the way macaroons do.
Why this matters in production
Most real agentic products aren't fleets of distinct agents. They're one agent serving thousands of customers, each with their own role, plan, and data scope. If your authorization layer only knows which agent is running, every tool wrapper has to re-implement "which customer is this, what can they touch," and that's where bugs live. Hexgate moves that question into policy.
Where AGT pulls ahead
AGT is the first open-source toolkit advertising coverage of all 10 OWASP Agentic Top 10 risks, with a broader surface: MCP security gateway, agent hypervisor, trust scoring across delegation chains, EU AI Act / HIPAA / SOC 2 mapping. If your audit team wants a single artifact that maps to a compliance framework, AGT has more ground covered out of the box.