The Enterprise AI Agent Integration Layer

TL;DR

Connecting an agent to a system was never the hard part. OAuth is solved, most SaaS platforms have decent APIs, and MCP gives everyone a common way to describe a tool. What's hard is that "Gmail access: yes" collapses reading a thread and deleting it into the exact same permission, and nobody notices which one got used until after it happened.

Most integration work still stops at reach: it answers whether an agent can call a tool. It rarely gets to whether this agent, acting for this person, should be allowed to call it right now.

Most of what an agent does should just happen without anyone watching it happen, so this isn't a case for a human reviewing every action, or for slower agents generally.

The case is narrower: decide, per action, which things are which, before an agent takes them rather than after an incident review. We think the useful test for any integration layer is whether it can grant the read and withhold the send, and whether it can tell you afterward, in a record it didn't write itself, that it tried.

Overview

An agent that only 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 into a production system. Enterprises are increasingly deploying the second kind, and that's what has changed what an integration layer needs to do.

None of the individual pieces are hard anymore. OAuth is a solved problem, most SaaS platforms have usable APIs, and the Model Context Protocol gives the industry a common way to describe and call a tool. A competent engineer wires an agent to Gmail in an afternoon and calls the integration done. We think that's exactly where teams get into trouble: the afternoon of work that gets an agent talking to a system looks, from the outside, indistinguishable from the much harder work of deciding what it should be allowed to do once it's there.

That's the gap the integration layer sits on top of, whether anyone designed it to or not. It's the one place in the stack where an agent's intention has already resolved into something concrete: a named tool, a specific set of arguments, an identified user, a chosen credential. Nothing upstream carries that much information, and nothing downstream can tell the agent apart from the person it's acting for. A quarter later, when someone asks what actually happened, this is also the only place positioned to give an honest answer.

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 gets 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 just "Gmail." So are reading source code and merging straight to production, or running a SELECT and dropping the table underneath it. The integration decides what an agent can reach. Authorization decides what it's allowed to do once it's there, and most of what the industry currently sells is still aimed at 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 gets 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 isn't 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 flavors, neither of them good. Either the agent holds a service account, so every action it takes lands on a robot with more authority than any individual employee has, and the acting user disappears from the record entirely. Or the agent holds the user's own token, so it inherits that person's full authority, including plenty they'd never sign off on delegating to an autonomous process, and this time it's the agent that vanishes from 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 benefit that's easy to miss: it can run before the agent ever sees the tool catalog. A tool outside the intersection doesn't need to appear in the list at all, and an agent that can't see gmail_delete_message can't be argued into calling it, and an injected instruction hidden in a retrieved document has nothing to steer it toward. That's not a substitute for enforcing the same rule again at call time, since a tool name that leaked into an earlier transcript or a cached list is still callable. But filtering the catalog removes a large class of attempt before it ever 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 it can disclose it just as easily. 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 still isn't a solved problem. The strongest published defenses report partial mitigation on adversarial benchmarks, not elimination, so the working assumption has to be that an agent will sometimes get successfully talked into the wrong action. What determines the outcome is what that wrong action was allowed to be. An agent that can read and draft but not send, whose reach is bounded at the tool boundary instead of 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 already 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 is still someone else's job: the intersection, the action-level decision, the audit event all belong to whatever sits behind the server.

Databases make the read/write split unusually stark, which is part of 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 hard case: the ones running the business, and the ones no vendor connector reaches. Internal services sit behind a firewall with no public endpoint, by design, and the fix can't be giving them one. An outbound-only connector solves this the way a lot of internal tooling already does: the internal network dials out and nothing dials in, so the system stays unreachable from the internet while a governed tool call can still 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 says which user initiated the request, which agent acted on it, which tool and action ran, what the authorization decision was, and what came back from the downstream system.

The part that gets overlooked is provenance. An audit trail assembled from the agent's own logs, its transcript, its self-reported tool calls, its own summary of what it did, makes the entity under investigation the author of the evidence too. That's the same reason an application does not get to write its own access logs. The record has to come from the layer that made the decision, at the moment it made it, including the calls it refused.

Denied attempts barely make it into most trails, which is a shame, because they're the good part. An allowed call just tells you the system worked as configured. A denial tells you an agent tried to do something outside its bounds, which is either a misconfiguration worth fixing or the first visible sign 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's 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, 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 a human to approve. The decision at the boundary is allow or deny. We think that's worth stating plainly: the category talks about approval workflows constantly, and a buyer should be able to tell which capabilities are enforced today and which ones are still a box on a diagram.

Conclusion

This was never really about getting two systems to talk to each other. OAuth handles that, MCP handles that, and an OpenAPI import handles most of what's left. What's actually at stake is authority: how much of it an autonomous process gets handed, whose it's borrowing when it takes an action, and, months later, whether anyone can reconstruct what happened and why.

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