Introducing GraphOS Agent Services
Adam DeLisse
Creating your first agent was easy. Someone pointed an MCP client at a few internal services, wrote some skills by hand, and in a couple of days it was summarizing campaign performance emails or triaging tickets. Leadership really liked your demo.
Onboarding your tenth agent is a little different. A dozen MCP servers are registered across your teams’ clients, exposing a hundred tool definitions amongst them. Every server holds its own credentials and reaches upstream services using a service account that maps back to no individual or team. Some of your agents aren’t using MCP at all. They’re hitting your REST API with a key someone pasted into an environment variable, and whatever comes back ends up in the agent context for the rest of the session. The problem continues to compound as you add more agents.
Ask for a customer’s name, and you often get far more: their address, their account information, maybe even their billing information. Every extra field costs tokens. Every field the agent shouldn’t have seen is now in its context window.
When your security team asks whether your marketing agent can see customer PII, someone has to manually go read individual tool definitions. When your infrastructure team asks who is generating all the new backend traffic or wants to throttle a single misbehaving client, they have to work backwards from API key to a human.
And nothing is recorded in a form a security team can use in a formal audit. Tool calls return opaque blobs, so “what did the agent see” requires in-depth investigation, if it’s available at all.
This is where your company’s agent programs stall. Not on capability. Not on appetite. Not even necessarily on budget. They stall on the review process your security team decides has to happen before a capability reaches production, because they have to guard against the previous security leak caused by a rogue agent. Nobody is able to say what the agent will touch before it touches it.
Agents are probabilistic. Controls on them can’t afford to be. But a rule like “support can’t see credit scores” only works if the system knows which value in a response is a credit score. Most APIs don’t provide that level of insight. They return a blob, and the only choice is to allow the whole call or block it. That extra level of precision requires a domain model of your business. The systems, the services, the entities inside them, how they relate, and the rules for who can see and do what.
Today we’re announcing the public preview of GraphOS Agent Services to help organizations build and manage the domain model that controls and audits what your agents can see and do. It adds new agent-focused capabilities to GraphOS:
- Search, so agents can find the right data and tools from a large domain model
- Identity, to manage credentials for an agent acting autonomously or on behalf of a human, brokered all the way down to the data source
- Policy, so users can control exactly what each agent can see and do, down to an individual field
- Audit, so there is a a precise log of everything that happened for observability, insights, and compliance
Putting Agent Services in action at Intuit
Intuit is already live in production with GraphOS and is piloting GraphOS Agent Services in preview, running an intelligent business on top of real-time data.
“Our marketing team used to wait weeks to learn which campaigns were working and weeks more to turn around a change, even when the fix was obvious. Every day of delay cost us real money,” said Chris Miller, Head of AI Marketing Futures at Intuit. “Now our agents can analyze spend against results and propose a change in real time, because GraphOS Agent Services gives them access to only what they need and keeps an audit trail of everything. That’s the only way we’d trust giving them this kind of authority.”
Why the graph
Your business is already graph-shaped. A customer in your CRM has accounts. Each account has invoices in your billing system. A disputed invoice ticket points back at both the customer and the invoice. A graph models these relationships as they already exist instead of as a pile of separate endpoints.
That shape is what lets rules be written about specific data. Because the graph knows the address of a customer’s credit limit or a ticket’s internal notes, a rule can name exactly those fields. GraphOS Agent Services resolves every agent through a graph, so those rules can be applied deterministically, field-by-field. No model sits in the judgement loop.
Model the systems you already have
Most of what your agents need lives in internal services nobody has modeled, whether it’s the REST API behind your billing platform or an internal service only one team actually understands. Before policy can reach those services, they have to be onboarded to your domain model.
Your domain model lives in a service catalog and is accessed by agents through the search service. It includes every connected service, the entities inside those services, and how they relate.
You’ll be able to add first party and third party APIs alike to the catalog, assisted by Apollo’s engineers. The process is sped up with the new GraphOS Factory skill, now available in preview. With the skill, agents under Apollo’s direction consume API documentation to quickly integrate REST APIs into Agent Services. The service comes under policy as soon as it’s published, and nobody has to write schema by hand.
Already have a graph? You can add that to the catalog too.
Govern every request
GraphOS Agent Services provide a single endpoint every agent connects to. Agents never hold upstream credentials; their identity is brokered by Agent Services. Every request is checked on the way in and every response is checked on the way out.
Know who’s acting
Every agent has its own app identity, with a scoped key validated at runtime. No developer’s credential ends up embedded in a tool the whole company uses.
When a person is signed in, their identity travels with the request, brokered from the MCP client all the way to your upstream systems. Credentials are exchanged per person, so the agent reaches your system under the identity of the person that asked. The agent never holds upstream credentials.
That means you can build one agent instead of one per department. Say a support rep and a finance analyst both ask the same agent about the customer with the disputed invoice. That’s two requests with two identities. Both see the invoice, but only the finance analyst sees the customer’s credit limit. Tagging that field with a financial classification and defining a policy based on that tag denies financial data access to the support rep.
An app’s own rules never override organization-wide policies. As an org admin, you decide per-agent whether its access depends on who is using it. Bind a policy to an app alone, and the agent keeps the same access no matter who is driving it.
Control what it can touch
Fields carry classification tags. Policies are written against those tags, the agent’s app identity, and the person the agent is acting for. A field with no classification tag isn’t restricted, so tagging is how you mark what’s sensitive. Restricted data never reaches the agent.
You decide how much the agent learns about what it didn’t get:
- Mask returns the field as null with no error. The response keeps its shape.
- Deny/visible returns null with an error saying the field was denied.
- Deny/requestable returns null with an error saying access can be requested.
- Deny/hidden omits the field entirely. It’s never requested from the upstream system, and its existence isn’t even disclosed.
Denying a write blocks execution before it ever reaches your system.
Get unblocked without a ticket
When an agent hits a requestable field, the person using it asks for access in their agent session, in the chat they’re already using. An admin can approve or deny the request field-by-field. The requestor never has to use a different tool at all.
Stop rogue agents with a single toggle
When an agent misbehaves, you suspend its identity instead of hunting for which secret to rotate. Suspension is a policy change, so every request path picks it up, and the agent is cut off from everything within seconds.
Prove what happened
Logging everything and reviewing it later isn’t protection. Once a field resolves into an agent’s context, it’s too late. It can end up in a summary, a downstream tool call, or a model provider’s logs. There’s no rolling back a context window.
Prevention is the protection. The record is the proof.
Observability records every request: the acting app, the person it acted for, the operation, the classification tags involved, the policy decision, the systems reached, and the outcome. Because the gateway enforces identity on every request, “who did this?” always has an answer.
The record includes what was withheld, not only what was served. A gateway that only sees opaque blobs can tell you a call was allowed or denied. It can’t tell you that three fields were stripped before the agent saw them.
When taken in aggregate, denials also show you what people and agents are trying to do with your data. Some point to a policy that’s too tight. Some point to an agent that’s reaching further than it should, or to someone probing for data they shouldn’t have. Before, those attempts either succeeded silently or failed where nobody could see them.
A denial is a signal, not a dead end.
Security review, with an end
Most enterprises aren’t short on agent ideas. Leadership wants more AI, and faster. Security wants to know what agents will touch before they touch it. The work is stuck in between.
With identity on every request, field-level policy control, and a record of what every agent did, security review becomes a process with an end. Teams experiment without needing an exception. Security grants access to a specific, bounded set of data instead of saying no to a whole category. When something goes wrong, you know what happened and who did it, and you can cut it off with a single toggle.
GraphOS Agent Services is available today in preview. Pick the AI initiative stalled in review at your company, then join the waitlist to talk with us about what it would take to ship it.
