Preventing Agent Hijacking With Cryptographic Identity and RBAC

If you’re letting AI agents call tools, open pull requests, touch production data, or coordinate work across services, you already have an identity problem. A lot of agent systems still rely on soft trust: API keys in environment variables, tool access based on network location, or a vague assumption that “the agent running in this session is the same one we started with.” That works right up until it doesn’t. An agent gets replayed, a tool call is spoofed, a session token leaks, or a delegated workflow quietly gains more access than intended. That’s agent hijacking in practice: an attacker, buggy integration, or misconfigured workflow causes actions to be executed by the wrong agent, with the wrong permissions, and without a reliable way to prove what happened. The fix is not “more prompts.” It’s the same thing we’ve learned in every other security domain: strong identity, least privilege, and auditable authorization. What agent hijacking actually looks like In most real systems, hija