Michael JohnsonOn October 7, 2026, Apollo GraphQL introduced GraphOS Agent Services — a preview service for managing AI agents’ access to enterprise APIs. Administrators can allow, mask, or deny access to individual data fields. Onboarding is arranged with Apollo’s assistance.
What Apollo introduced
According to the company, Agent Services sits between an agent and internal systems: it turns requests into API calls, handles credentials, and enforces restrictions. Apollo highlights four functions: discovering data and tools, identity management, access policies, and auditing. These are listed in the official service announcement.
The press release distributed on PR Newswire was published on October 7 at 12:02 p.m. U.S. Eastern Time, or 7:02 p.m. Moscow time. That is the publication time of the announcement; the exact time access opened is not stated separately.
Why limit an agent’s access
A practical Apollo scenario involves one agent working with different employees. In the example in the company’s blog, a support representative and a financial analyst request information about a disputed invoice. Both receive the invoice, but only the analyst can access the customer’s credit limit. The distinction is set through field classification and an access policy.
This approach can help teams connecting agents to customer, financial, and other internal services: permissions can be defined for specific data and take into account who assigned the agent its task. Apollo also reports a pilot at Intuit. GraphOS is already in production there, while the new Agent Services is being tested in preview. The company links the pilot to analyzing marketing spend; the announcement provides no quantified savings results.
How the rules work
According to the access rules documentation, a rule defines the user or group, the calling application, the data being protected, and the outcome of the check. Fields are classified with tags; a rule can apply to a tag or a service. Three effects are available: return the value, mask its contents, or deny access.
For denied access, there are several options: omit the field from the response entirely, return an error, or allow a request for additional access. If a field has multiple tags, the stricter effect takes precedence: denial outranks masking, and masking outranks allowing access.
An important configuration detail: Apollo warns in its administrator guide that the service does not yet validate a user or group identifier with the identity provider. A typo causes the rule to stop matching requests without notice. Testing the actual outcome for each role should therefore be part of the pilot.
According to Apollo’s architecture description, the policy engine makes access decisions without involving a language model. It also says that a field without a classification tag remains unrestricted. However, the documentation overview recommends denying access to fields in a connected service before granting permissions. These statements call for checking the specific configuration: teams should separately test access to tagged and untagged fields.
Auditing and availability
The Monitor guide describes a request log containing the time, client, tool, operation, affected service, and outcome of policy enforcement. For an individual request, users can see which rules were triggered and which fields were masked or denied.
An important limitation of the audit: the response viewer shows its structure and the fields that were changed, but not the values returned by the source service. Any review of the response’s specific contents needs to be planned separately. CSV export covers requests loaded on the current log page.
The sources differ in how they describe the access stage. In its October 7 blog post, Apollo announces a public preview and offers a waitlist. The service documentation calls the stage a private preview and says onboarding requires assistance from an Apollo employee. The documentation page has no update date, so it is not possible to establish the order in which these descriptions appeared.
The practical next step is to arrange a pilot with Apollo. The reviewed materials do not specify a stable-release timeline or pricing for Agent Services. Before connecting, a team should define the fields available to the agent, identify permission owners, and prepare test requests for each role.