MCP servers for SAP, Salesforce, ServiceNow and internal APIs
Cohash connects AI agents to SAP, Salesforce, ServiceNow and internal APIs through MCP servers. We use the vendor's hosted server where there is one and build our own for internal systems. Each server is an OAuth resource server with audience-bound tokens. Tools are scoped to the job, writes wait for approval where they matter, and every call is logged with the user and agent behind it.
- 01Tool design per use case
- 02Vendor server or custom build
- 03Authorization
- 04Approvals and limits
- 05Logging and registry
The story
Told without the client's name or anything that could identify them.
A manufacturer's IT group had AI agents reaching its CRM and service desk through one integration user with admin rights, and other teams were installing community MCP servers from GitHub with no review of the tools they exposed. When someone asked for an agent that could create purchase orders in SAP, security paused new agent work until every action could be traced. We started from the tasks the agents had to do and designed a small set of named tools per system. The group ended up on vendor-hosted servers for Salesforce and ServiceNow, the AWS server for SAP, custom servers for internal APIs, and one audit trail that shows the user and the agent behind each call.
why it was urgentThe big vendors now ship MCP themselves. Salesforce Hosted MCP Servers went generally available in April 2026 for Enterprise Edition and above. ServiceNow added MCP Server Console in Zurich, with clients connecting over OAuth. AWS made its MCP server for SAP S/4HANA and ECC generally available in Amazon Bedrock AgentCore on 1 May 2026. The spec itself is on its 2026-07-28 revision.
- openAn agent reaches the CRM through one integration user with admin rights.
- recurringPeople are installing community MCP servers off GitHub, and nobody checks what tools those servers expose.
- blockedAudit logs show every agent action under the same service account.
- openSomeone asked for an agent that can create purchase orders in SAP.
The estate, before and after
Before: agents on a shared admin key and unreviewed servers
One integration user with admin rights was how agents reached the CRM and service desk. Some agents ran community MCP servers nobody had reviewed. Scripts with stored keys called SAP and internal APIs, so every action showed up under the same account.
After: governed MCP servers per business system
Agents act for the signed-in user with audience-bound tokens from the identity provider, and call one MCP server per system. Writes that matter pass an approval step, and every call lands in an audit log with the user and agent IDs.
How we run it, phase by phase.
5 phases take you from Agents on shared admin keys and one-off scripts to Governed MCP servers per business system. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Tool design per use case
Start from the task. List the reads and writes the agent needs, then design a small set of named tools with narrow inputs. A generic query or execute endpoint is what to avoid.
- phase 02
Vendor server or custom build
Where Salesforce Hosted MCP Servers, ServiceNow MCP Server Console or the AWS server for SAP fit, we use them. Custom servers are for internal APIs and the workflows those vendor tools don't cover.
- phase 03
Authorization
We run every server as an OAuth 2.1 resource server that publishes Protected Resource Metadata. It accepts only tokens issued for its own audience and never passes a client's token on to downstream APIs. Where the action belongs to the user, the agent acts for the signed-in user.
- phase 04
Approvals and limits
Writes with money, customers or records of account attached need human approval. Rate limits and per-tool quotas stop a looping agent from flooding a system.
- phase 05
Logging and registry
We log each tool call with user ID, agent ID, inputs and result. Approved servers go into an internal registry with an owner, a version and the spec revision they implement.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Every tool call names the user and the agent
Every call is logged with user ID, agent ID, inputs and result. When something changes in SAP or Salesforce, we can see which person and which agent did it, instead of a shared service account.
- result 02
Agents work through narrow, named tools
Use cases each got a short list of tools with narrow inputs. We didn't build a generic query or execute endpoint, so no agent has admin reach.
- result 03
Tokens only work on the server they were issued for
We set up each MCP server as an OAuth 2.1 resource server that publishes Protected Resource Metadata. It only accepts tokens for its own audience and never forwards a client's token downstream.
- result 04
Writes with money or customers attached wait for a person
Purchase orders, customer records and other records of account need human approval before the write goes through. Per-tool quotas stop a looping agent from flooding a system.
- result 05
One registry of approved servers
We listed approved servers with an owner, a version and the spec revision each implements. Teams reuse them instead of building a second server for the same system.
Risks we plan for
-
Tools that do too much
Give an agent a tool that runs any SOQL query or calls any OData service, and you've given it the same reach as an admin. OWASP calls this excessive agency.
-
Token passthrough
If a server forwards the client's token, or sits on broad credentials of its own, it turns into a confused deputy. The MCP authorization spec bans token passthrough for exactly that reason.
-
Instructions in returned data
Case notes, emails and descriptions can carry text written to redirect the agent. We treat returned data as untrusted, and sensitive tools need confirmation.
-
Server sprawl
Teams building separate servers for the same system end up with duplicate credentials and gaps in audit. We use a registry and shared patterns to prevent it.
Where AI helps, and where it needs guardrails
Vendors now ship MCP themselves. Salesforce's hosted servers keep existing Salesforce permissions, ServiceNow builds MCP tools from Now Assist skills, subflows and REST APIs, and SAP added MCP support to Joule Studio. Our work is the governance between them: agent identities, scoped tokens, approvals for writes and one audit trail across systems, so an agent working in SAP and Salesforce is traceable in both.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Tool catalogue per system with scopes, inputs and approval rules
yours to keep - code02
MCP server code or vendor server configuration, in version control
yours to keep - document03
OAuth client, audience and scope configuration in the identity provider
yours to keep - evidence04
Audit logging with user and agent IDs, and dashboards for tool use
yours to keep - report05
Internal MCP server registry with owners and review status
yours to keep
Platforms and services on this move
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01MCP server
- Software that gives agents tools over the Model Context Protocol. If you switch on authorization, it treats agents like any other API client and checks their OAuth tokens.in context →
- 02integration user
- A Salesforce account used by another system, not a person. Entra's provisioning connector signs in as one.in context →
- 03OAuth
- A way for programs to sign in with tokens that expire quickly, so a leaked one doesn't work for long. Zendesk's last 30 minutes by default.in context →
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Should we use the vendor's MCP server or build our own?
Use the vendor's where it covers your tools, since it inherits the platform's permission model and gets maintained with it. Build your own for internal APIs and for business logic that spans systems.
02Is MCP safe for production systems?
It can be, if each server is treated like any other API. The spec requires OAuth 2.1 for HTTP servers that use authorization, with audience checks on every token. The risk is in servers that skip those steps.
03Can agents write to SAP or Salesforce?
Yes, with scoped tools. We start read-only and add writes one at a time. Anything with financial or customer impact needs approval until we know the error rate.
04Do you also handle agent identity?
Yes. We give each agent its own identity with an owner, and it works with short-lived tokens delegated from the user. You can trace what it did and switch it off without affecting anyone else.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyAI pilot to production with forward deployed engineers
Taking an AI pilot into production with forward deployed engineers who work with the business team, build evals, connect real systems and hand over cleanly.
read the case study9442fb7a - 01Book a 30-minute working sessionsenior engineer
- 02Talk to an engineer about your setupreply within 24 hours
- 03See how similar projects wentcase studies
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it