Your agents are moving from pilot to production, and someone on your team is about to make an architecture decision that will shape your AI security posture for years: how do agents actually get authorized to touch your systems at runtime?
There are two credible ways to answer that question, and most vendors will tell you theirs is the only one, usually because it's the only one they built. In reality, each approach has real strengths, and a platform worth adopting supports both.
Approach one: the gateway#
In the gateway model, the platform sits as a proxy between the agent and the application. Every request the agent makes passes through it. The gateway checks the agent's identity, evaluates policy, and allows, blocks, or escalates the request in real time.
The defining property of this model is visibility. Because every call flows through the gateway, the platform sees and logs the end-to-end flow: what the agent asked for, what policy said, what the application returned. When you need to answer "what did this agent actually do last Tuesday," the gateway has the complete picture.
That makes the gateway the right fit when deep inspection matters. High-sensitivity systems, agents you're still building trust in, environments where auditors will want the full transaction trail. The trade-off is that the proxy is in the data path, which means the provider's infrastructure sees your traffic.
Approach two: the Enterprise Managed Authorization standard#
The second model uses an authorization standard like the enterprise-managed authorization (EMA) standard. Here, the agent talks to your application directly. No proxy in the middle.
The flow works like this: you sign into your identity provider, the provider verifies who you are and what access level you hold, and then it mints a short-lived, scoped token for your agent. The agent uses that token to access the application directly, with exactly the permissions the token grants, for exactly as long as the token lives.
Two properties make this model compelling. First, no standing keys. Access exists only in short-lived, scoped tokens that expire on their own, so there's no long-lived credential to manage at all. Second, data privacy by architecture. Because the provider is not in the data path, it cannot see your application's data. It still produces access logs, so you know when tokens were minted and used, but the content of the interaction stays between the agent and your application.
This is the right fit when data sensitivity rules out a proxy, when latency matters, or when you want authorization anchored in an open standard rather than a vendor's data plane.
Why "both" is the only serious answer#
Look at the two models side by side and the pattern is obvious: their strengths are complementary, not competing.
The gateway gives you full-flow inspection, real-time policy enforcement, and secure, centralized credential management. The standards-based model takes standing credentials out of the picture entirely, pairing direct access with architectural privacy. No real enterprise environment is uniform enough for one model to cover everything. Your finance system and your internal wiki do not warrant the same authorization architecture, and neither do a brand-new experimental agent and a mature one that's been in production for a year.
A platform that only offers a gateway forces all your traffic through its proxy whether the sensitivity justifies it or not. A platform that only offers token-based access gives up the deep inspection that some systems genuinely require. Either way, you end up bending your security architecture to fit a vendor's product decision.
The question to ask a provider is not "gateway or tokens?" It's "do you support both, and can I choose per system, per agent, per policy?" If the answer is no, keep looking.
