The Enterprise AI Agent Integration Layer

Overview

An agent that answers questions needs a model and a context window. An agent that files a refund, merges a branch, or emails a customer needs a credential and a network path to a production system. The second kind is what enterprises are now deploying, and it changes what the integration layer is for.

Connecting an agent to an application is not the hard part. OAuth is a solved problem, most SaaS platforms have usable APIs, and the Model Context Protocol has given the industry a common way to describe and invoke tools. A competent engineer can wire an agent to Gmail in an afternoon. The question that afternoon does not answer is whether the agent should have been allowed to send that particular message, on behalf of that particular person, at that particular moment — and, a quarter later, how anyone would reconstruct what it actually did.

That gap is why the integration layer is quietly becoming a control point. It sits at the only place in the stack where an agent's intention has been resolved into a concrete request — a named tool, a specific argument set, an identified user, a chosen credential — but has not yet reached the system that would honor it. Nothing upstream has that much information. Nothing downstream can tell an agent apart from the human it is impersonating.

What Changes When an Agent Can Act

Traditional integrations connect known systems through predictable paths. A nightly job moves records from a billing system into a warehouse. A user signs into an application and clicks through a workflow someone designed. The set of possible actions is enumerated in advance, because a person wrote them down.

An agent breaks that property. It interprets an instruction, selects a tool from whatever catalog it was given, composes arguments, and executes. The path is user → agent → tool → credential → system → action, and the middle of that chain is decided at runtime by a model responding to text it did not author. Some of that text comes from the user. Some comes from a retrieved document, a ticket body, a webpage, or the output of the previous tool call. This is what makes agents useful and also what makes "the agent has Gmail access" an inadequate description of the risk.

Reading an email and deleting one are both Gmail. Reading source code and merging to production are both GitHub. Running a SELECT and dropping a table are both the database. The integration determines what an agent can reach; authorization determines what it may do once it is there. Most of the industry's tooling is still concentrated on the first of those.

There is a further asymmetry. When a human misuses an application, the blast radius is bounded by how fast a person can click. An agent operating in a loop can attempt hundreds of actions in a minute, and a single poisoned instruction is reproduced identically across every user that agent serves. OWASP's 2026 Top 10 for Agentic Applications names this directly under Identity and Privilege Abuse (ASI03): the architectural mismatch between user-centric identity systems and agentic design leaves agents operating in what it calls an attribution gap, where enforcing least privilege is not merely neglected but structurally impossible.

Two Identities on Every Request

The single most consequential design decision in an agent integration layer is whether a request carries one identity or two.

One identity is the common case, and it comes in two equally unsatisfying flavors. Either the agent holds a service account, in which case every action it takes is attributed to a robot with more authority than any individual employee, and the acting user is lost. Or the agent holds the user's own token, in which case the agent inherits precisely the user's authority — including everything that user can do but has no business delegating to an autonomous process — and the agent becomes invisible in the record.

Two identities means the request asserts both: this agent, acting for this person. The authorization decision is then a function of both, and the natural function is intersection. The agent's declared scope is a ceiling on what it may ever do, independent of who invokes it. The user's authority is a ceiling on what may be done in their name. The effective permission is the smaller of the two, which means a shared agent used by five hundred people behaves differently for each of them, and no user can gain authority by routing a request through it.

Figure 1 — A governed tool call. The agent presents two identities and receives a decision, not a credential.

The intersection has a second, less obvious benefit: it can be applied before the agent ever sees the catalog. If a tool falls outside the intersection, it does not need to appear in the tool list at all. An agent that cannot see gmail_delete_message cannot be argued into calling it, cannot hallucinate its parameters, and cannot be steered toward it by an injected instruction in a retrieved document. Filtering the catalog is not a substitute for enforcing at call time — both are necessary, because a tool name that leaks through a transcript or a cached list is otherwise still callable — but it removes a large class of attempt before it starts.

Credentials the Agent Does Not Hold

Agents need OAuth tokens, API keys, database credentials, and service-account secrets to do anything useful. It does not follow that they need possession of them.

The distinction is between having the power of a credential and having the credential. An agent that holds a raw token can use it for anything the token permits, in any order, at any rate, for as long as it lives — and can also disclose it. Tokens end up in reasoning traces, in prompt-cache entries, in error messages returned to a model, in logs, and in the arguments of the next tool call. Any of those can be exfiltrated by an injected instruction, because from the model's perspective a secret in its context is just more text.

The alternative is a reference. The agent holds an opaque handle to an authorized connection; the control layer resolves that handle to a real credential at the moment of execution, applies it to an outbound request it constructed itself, and returns only the response body. The secret never enters the agent's runtime or its context window. Rotation becomes an operation on the store rather than a redeployment of every agent. Revocation becomes immediate rather than eventual.

Permissions at the Action, Not the Application

Application-scoped access is the wrong granularity for autonomous software, and this becomes obvious as soon as the actions are written out.

"Gmail access: yes" collapses that entire table into a single bit. The company that grants it has not decided that the agent may permanently delete mail; it has simply not been asked. The right boundary is the individual action, because the individual action is where the consequences differ.

This granularity also changes what a compromise costs. Prompt injection is not fully solvable — the strongest published defenses report partial mitigation on adversarial benchmarks, not elimination — so the design assumption has to be that an agent will sometimes be successfully instructed to do the wrong thing. What determines the outcome is what the wrong thing was allowed to be. An agent that can read and draft but not send, whose reach is bounded at the tool boundary rather than by a paragraph in a system prompt, has a bad afternoon instead of an incident.

Some actions sit between "allow" and "deny" and genuinely want a third state: hold, and ask a person. That capability is worth being precise about, because it is frequently described as though it were a property of an integration when it is really a workflow with a queue, a notification path, an expiry policy, and a UI. Teams evaluating platforms should ask whether an approval step exists as an enforced control or as an instruction in a prompt. Only one of those survives an agent that has been talked out of following instructions.

Connection Paths

No single mechanism reaches everything an enterprise agent needs, and a platform that offers only one is making a bet on where the work happens.

Prebuilt SaaS integrations cover the systems everyone has — mail, files, calendars, chat, source control. Their value is not that they exist but that they can be decomposed: an integration that exposes one coarse "Gmail" permission is much less useful than one that exposes each operation as a separately governable action.

OpenAPI is how the long tail gets in. Most companies run proprietary services that will never appear in any vendor's connector catalog, and most of those services already have a specification. Importing it and exposing selected operations as tools turns an internal API into agent-callable surface without anyone writing a connector.

MCP standardizes discovery and invocation, which is genuinely valuable and genuinely insufficient. The protocol establishes how an agent finds a tool and calls it; it does not decide which agent may reach which server, whose authority the call carries, or what gets recorded. The 2026-07-28 revision made MCP servers formal OAuth 2.1 resource servers, which sharpens authentication considerably. Authorization — the intersection, the action-level decision, the audit event — still belongs to whatever sits behind the server.

Databases make the read/write distinction unusually stark, which is why read-only is a defensible default. An agent that answers questions from business data needs SELECT. Granting it more because the connection string happens to permit more is an accident, not a decision.

Private systems are the ones that matter most and are reachable least. Internal services behind a firewall have no public endpoint by design, and the answer cannot be to give them one. An outbound-only connector — the internal network dials out, nothing dials in — keeps the system unreachable from the internet while still letting governed tool calls reach it.

Figure 2 — Five connection paths, one decision point. The value is that the same authorization and the same record apply to all of them.

The Evidence Problem

When an agent changes a business system, someone will eventually need to explain what happened. A useful record answers which user initiated the request, which agent acted, which tool and action were invoked, what the authorization decision was, whether it succeeded, and what the downstream system returned.

The requirement that gets overlooked is provenance. If the audit trail is assembled from the agent's own logs — its transcript, its self-reported tool calls, its summary of what it did — then the entity under investigation is also the author of the evidence. That is unacceptable for the same reason an application does not get to write its own access logs. The record has to be emitted by the layer that made the decision, at the moment it made it, including the calls it refused.

Denied attempts are the most informative events in the entire trail and the ones most often missing. An allowed call tells you the system worked. A denial tells you an agent tried to do something outside its bounds — which is either a misconfiguration worth fixing or the first visible symptom of an injection attempt.

Where Agentic Fabriq Fits

Fabriq is a control layer for AI agents. Rather than every agent carrying its own authentication logic and its own credentials for every system it touches, agents route tool calls through a single governed path, and the decisions described above are made in that path.

Each registered agent has its own identity and its own declared scopes. The acting user's identity travels with the request, and the effective permission is the intersection of the two, applied both when the tool list is assembled and again when a call is made — so a tool that was visible when a session opened is still re-checked when it is invoked. Agents operating in action mode are gated on explicit per-user action grants instead, with the same "smaller set wins" shape. Credentials live in a vault and are injected at call time in the default proxy mode, so tokens do not enter the agent's runtime. Access can be narrowed or cut centrally: an agent can be disabled organization-wide, a user's authority can be reduced, and a connection can be removed, without touching each downstream application.

The connection paths are the ones above: built-in integrations across Google Workspace, Microsoft 365, Slack, GitHub, and Notion; OpenAPI services imported as tools; existing MCP servers brought under the same controls; Postgres with SELECT-only guardrails; and an outbound-only connector for systems inside private networks. Every governed call produces an audit event recording the agent, the acting user, the tool, the authorization mode, the gate decisions, and the outcome — denials included.

What Fabriq does not currently do is hold an action for human approval. The decision at the boundary is allow or deny. That is worth stating plainly, because the category talks about approval workflows constantly and buyers should know which capabilities are enforced today rather than described in a diagram.

Conclusion

The first wave of AI infrastructure made models more capable. The second gave them tools. The current one is about authority: how much of it an autonomous system gets, whose it is borrowing, and what evidence exists afterward.

Those decisions land in one place. Between the agent's intention and the system that would honor it, there is exactly one point that knows the agent, the user, the tool, the action, and the credential simultaneously. Whatever code occupies that point is the security boundary for production agents, whether or not it was designed to be.

Sources

• OWASP Top 10 for Agentic Applications 2026 — ASI03 Identity and Privilege Abuse; least agency and strong observability as framing principles
• Model Context Protocol specification, 2026-07-28 — stateless core, Extensions, Tasks, authorization hardening
• MCP authorization specification — MCP servers as OAuth 2.1 resource servers
• RFC 8693 — OAuth 2.0 Token Exchange — delegation with sub and nested act actor claims
• RFC 9700 — Best Current Practice for OAuth 2.0 Security
• OAuth 2.1 draft — the baseline MCP now aligns to
• draft-klrc-aiagent-auth-00 — modeling AI agents as workloads needing identifiers and credentials
• NIST AI Risk Management Framework
• CaMeL: Defeating Prompt Injections by Design — partial mitigation on AgentDojo, not elimination
• AgentDojo — benchmark for prompt-injection defenses in tool-calling agents
• SPIFFE — workload identity primitives underlying agent identity proposals
• Agentic Fabriq documentation — integration hub, agent scopes, audit trail