People will not use one AI agent for everything.

They may use Claude for research, Codex for engineering, an agent inside a product for support, and a custom multi-agent workflow for operations. Every agent will need access to many of the same business applications, from email and calendars to CRM, documents, collaboration tools, and internal APIs.

That creates a new infrastructure question: how should many AI agents reach many applications on behalf of the same person?

Connecting every agent directly to every application creates a growing web of accounts, permissions, credentials, and lifecycle controls. Every new agent and connector adds another set of relationships to operate.

We think there is a cleaner model: one identity-aware gateway between the agents people choose and the applications where their work already lives.

The AI agent gateway

The high-level architecture has three parts. AI agents sit on one side, connected applications sit on the other, and NamoID Agent Gateway provides the shared identity and access layer between them. The user's existing login supplies the human identity behind the request.

The architecture gives every participant a clear role:

Claude, Codex, and other agents plan work and request tools.
NamoID Agent Gateway connects each request to the right person, connected account, and permitted tool surface.
Business applications remain the systems where data lives and work happens.

NamoID does not need to become the model or replace the user's primary applications. It provides the common layer that connects identity, agents, and tools.

One connector catalog for the tools people already use

The NamoID connector catalog currently covers:

Google Workspace: Gmail, Google Calendar, Google Drive, and Google Sheets;
Microsoft: Microsoft 365 and Microsoft Teams;
Developer and collaboration tools: GitHub and Slack;
CRM and customer operations: HubSpot, Freshsales, and Zoho CRM;
Business and communication tools: Zoho Books, WhatsApp Business, and Notion; and
many more through custom APIs, managed connectors, and remote MCP servers.

This range lets a product build workflows around real customer work instead of isolated demos. A sales agent can bring together CRM records, email, calendar events, documents, and team conversations. An engineering agent can combine GitHub context with Slack and internal systems. A support agent can work across customer records, product knowledge, and communication channels.

The goal is a growing connection surface that can serve many agent clients, rather than a separate integration catalog for every model or runtime.

From one-to-one integrations to a many-to-many network

Without a gateway, each new agent needs its own connection to every application:

Claude → Gmail, Slack, HubSpot, Notion…
Codex  → Gmail, Slack, GitHub, Google Drive…
Your agent → Microsoft 365, Zoho CRM, internal APIs…

With NamoID Agent Gateway, both sides connect through a common layer:

many agents → NamoID Agent Gateway → many applications

This changes the economics of adding agents and connectors. A new agent can discover a governed tool surface without rebuilding every provider integration. A new connector can become available to multiple agent experiences without moving provider credentials into each runtime.

It also makes agents more portable. Teams can choose Claude, Codex, an embedded assistant, or a custom agent based on the task while keeping a consistent relationship with the user's connected applications.

MCP is standardizing agent-to-tool connections

The Model Context Protocol has become an open standard for connecting AI applications to tools and data. Remote MCP support now spans major agent platforms, including Claude and the OpenAI Responses API.

That makes MCP an important part of the agent stack. It gives agents a common way to discover and invoke tools, much like a shared port for agent capabilities.

But protocol compatibility is only one part of production access. Products still need to know which person an agent represents, which customer account applies, which tools are available, and how access is revoked. The current MCP authorization specification reflects this direction through OAuth-based discovery, resource-specific access, and least-privilege scope guidance.

NamoID Agent Gateway is designed for this intersection: an MCP-native tool surface backed by human identity, connected accounts, short-lived sessions, and product policy.

A2A and the rise of multi-agent systems

The next wave will involve agents working with other agents, not only agents calling tools.

The Agent2Agent protocol is emerging as an open standard for interoperability between independent agent systems. It complements MCP: MCP connects an agent to tools and context, while A2A helps agents discover, communicate, and coordinate with one another.

As agentic workflows become multi-agent workflows, the access problem becomes more important. A delegated task may move between agents built by different vendors, but the user's identity and the application's boundaries still need to remain understandable.

The long-term gateway must therefore support more than tool calling. It needs to carry trustworthy identity and authorization context across agent handoffs, long-running tasks, human-in-the-loop approvals, and event-driven workflows.

The missing layer is agent identity

Agents are becoming a new interface to software. They can reason, plan, call tools, and coordinate work. Yet an application still needs clear answers to basic questions:

Which person is this agent acting for?
Which product introduced the agent?
Which connected account should it use?
Which tools may it call?
How long should that access last?
Where can a user or operator revoke it?

The model cannot answer those questions by itself. Model reasoning is not an authorization decision.

NamoID keeps the human identity at the centre. That identity can come from a product's existing authentication system or from NamoID Customer Identity. The agent becomes a client acting for a person within a boundary defined by the product.

This is the foundation for agent identity, delegated access, least-privilege tools, short-lived credentials, audit trails, and zero-trust agent infrastructure.

Credentials stay out of model context

An AI agent needs the ability to use an application. It does not need to see the durable provider credential behind that connection.

NamoID Agent Gateway keeps provider access and refresh tokens inside the NamoID vault. Each secret is protected with AES-256-GCM envelope encryption. In production, AWS KMS generates and wraps the data key, while authenticated encryption binds the ciphertext to its tenant, project, environment, owner, secret, kind, and revision. Moving encrypted bytes into a different context causes integrity verification to fail.

The agent receives a short-lived, opaque NamoID Agent Session Token instead of the application's OAuth token. NamoID returns that session token once and stores only its SHA-256 digest. The token points to one agent, one human identity, one deployment, one Gateway, and an expiry. It can be revoked without exposing or rotating the underlying provider credential.

Only after a tool call passes the Gateway's checks does NamoID decrypt the required provider token inside the execution boundary and call the application. Claude, Codex, the browser, the prompt, and the model context never receive that credential. Vault reads, writes, rotation, rewrapping, and denied access are auditable operations.

From the agent's perspective, the interface stays consistent. From the product's perspective, provider tokens do not need to travel through prompts or live independently inside every agent integration.

This separation matters as agents become more autonomous. Prompt injection, excessive permissions, and credential leakage cannot be solved by asking a model to behave. Infrastructure needs to enforce the boundary outside the model.

When an agent hallucinates, the Gateway checks the action

No gateway can reliably inspect a model's private reasoning and declare every sentence true or false. NamoID controls the point that matters operationally: the moment an agent tries to turn its output into an external action.

If an agent invents a tool, supplies arguments that do not match the tool schema, selects an unapproved account, exceeds an argument limit, or requests an operation outside the published Gateway, the request is denied before the provider is called. Unknown policy fields and malformed policy conditions also fail closed.

That lets NamoID contain the observable effects of hallucination and prompt injection:

Deny by default: the agent can call only tools published in the active Gateway revision.
Argument constraints: policies can require exact values, restrict values to an approved set, or cap numeric amounts.
Risk-aware decisions: policies can allow, deny, or require human approval based on the tool, its risk class, the agent's risk tier, the principal, and the arguments.
Human-in-the-loop approval: consequential calls can pause until the required approver or approval workflow authorizes that exact request.
Call budgets: atomic connector quotas stop excessive provider calls, including concurrent attempts, before another call reaches the provider.
Immediate containment: operators can suspend an agent or deployment, disable a Gateway, revoke a session, disconnect an account, or use environment and tenant kill switches.

NamoID also separates blocking controls from operational detection. Policies, schemas, approvals, quotas, and kill switches block synchronously. The security-posture layer surfaces near-exhausted budgets, elevated provider-error rates, missing recipient-domain controls, missing data-volume rules, unhealthy connections, and overdue access reviews so operators can investigate unusual behavior without silently granting the agent more freedom.

The principle is simple: an agent does not receive continuous permission merely because an earlier call succeeded. Every tool request is checked again against the current session, Gateway, account, policy, approval, quota, and runtime state. The model proposes an action; NamoID decides whether that action is allowed to leave the boundary.

An access layer for the agentic web

We expect the agent landscape to remain diverse. People will use frontier-model agents, coding agents, vertical agents, product-embedded copilots, voice agents, and custom runtimes. Their work will continue to span dozens of SaaS applications and private systems.

Open standards such as MCP and A2A will make those systems more interoperable. The durable opportunity is the identity and access layer between them: a place where human identity, agent identity, connected accounts, product policy, credentials, sessions, approvals, audit, and revocation come together.

NamoID Agent Gateway is our direction for that layer.

We are starting with bounded, read-oriented access and a root-operator-controlled preview. The aim is to validate the gateway with real agents, real applications, and focused customer workflows before expanding toward durable background agents, multi-agent delegation, event-driven automation, and higher-impact actions with explicit human approval.

The long-term idea is simple: people should be able to choose the agents that help them, while products keep one dependable way to connect those agents to the applications where work happens.

If you are building an AI agent that needs access to multiple customer applications, tell us about the agent, the workflow, and the first two tools at hello@namoid.in.

Related posts