Latest Posts
Profiles: Programming the Gatana Identity Layer
The gateway between agents and your systems is where identity, credentials, and access control live. Profiles are how you make that boundary do exactly what your organization needs — per user, team, token, or IdP claim.
So why MCP? Honestly: it doesn't matter that much.
The value isn't the protocol — it's the governed boundary between agents and your systems. MCP is simply the standard everyone already speaks at that boundary.
One gateway isn't one configuration
We've written before about why the boundary between agents and your systems is the natural place for governance: it's the one point all tool traffic passes through, whether an agent connects over MCP or calls tools through the HTTP API. But that only helps if you can express real organizational rules there. In practice, different users, teams, and agents need different credentials and different sets of tools, and a gateway that treats everyone the same can't capture that.
This is what Profiles are for. A profile is a bundle of configuration — credentials, allowed servers, allowed tools — that gets applied conditionally: to a user, a team, a token, a single session, or anyone whose identity provider says so. The same gateway behaves differently depending on who's connecting and in what context, regardless of which protocol they connect over.
The easiest way to see why that matters is through a few situations that come up in almost every organization.
"Our CRM only supports service accounts"
Plenty of company-wide systems don't support per-user OAuth. The CRM is a common example: maybe your Salesforce setup has a handful of department-level service accounts, and that's what everyone shares. How do you give agents access without either handing every department the same account or maintaining a separate gateway configuration per department?
With profiles, you create one profile per department, put that department's service account credentials on it, and assign each profile to the corresponding team. When someone from Sales connects — from Claude, Cursor, a script hitting the HTTP API, anything — their agent's CRM calls run under the Sales service account, and Marketing's run under theirs. Nobody handles a credential directly, and when a service account rotates, you update it in one place.
Because credential resolution is deterministic — locked assignments beat unlocked, user assignments beat team assignments, and there's always a defined fallback to user or server credentials — you can layer this without surprises. An org owner can even assign a profile in locked mode, so the department credential applies no matter what else a user configures.
"This agent should only be able to read"
You're deploying a support agent that should look things up but never write. Instead of standing up a separate, stripped-down server configuration, create a profile with tool restrictions: pick the read-only tools from each server, enable restrictive mode so nothing outside the profile is reachable, and bind it to the agent's personal access token.
Since the token carries the profile, the restriction follows the agent everywhere — the same limits apply whether it connects over MCP or calls the tools as plain HTTP endpoints. You can also apply a profile for just a single session by adding it to the gateway URL, which is handy when you want to try out a restricted setup before committing to it:
"Access should follow our IdP, not a spreadsheet"
Profiles don't have to be assigned by hand at all. Claim mappings apply profiles automatically based on what your identity provider says about the user. If your IdP sends:
you can map department: engineering to one profile and groups: platform-team to another — including matches on array claims and nested properties. Onboarding, offboarding, and re-orgs are handled where they should be: in your IdP. Gatana just reflects them, and agents' access follows automatically.
The point
Each of these scenarios is really the same question: given who this is, what should their agents be able to reach, and as whom? Profiles let you encode the answer once and have it enforced at the gateway — for every client, every model, and every way of reaching your tools, MCP or plain HTTP — without changing anything in the agents themselves. And because each profile has its own maintainers, the teams closest to a system can manage its access rules without going through the platform team.
Since all tool traffic already flows through the gateway, it's the natural place to put this kind of logic — and profiles are the mechanism that makes it expressive enough for how organizations actually work.
See it in your own org. The Profiles documentation covers everything above — creating profiles, claim mappings, tool restrictions, and credential resolution — in detail.