watsonx Orchestrate Security and Governance for IBM AI Agents and MCP Tools
IBM watsonx Orchestrate runs HR, procurement, sales and IT agents that read and write in Workday, SAP, Salesforce, ServiceNow and any system you connect through a tool or a remote MCP server. Between June and September 2026 IBM shipped an Agentic Control Plane, Enforcement Tracking into watsonx.governance, an AI Gateway that discovers Amazon Bedrock agents, and a GA AgentOps agent. Those are real governance controls. The question this page answers is which agent actions they stop before they happen, and which ones they only record.
Direct answer
watsonx Orchestrate security comes down to four decisions. Import only the MCP tools an agent needs, because the ADK accepts a comma-separated list or a star that imports every tool on the server. Keep team credentials off tools that write, because each key in a connection is passed to the MCP server as an environment variable. Use the control plane, guardrail plug-ins and watsonx.governance for policy, content and evidence. And put a per-call gate with a named approver in front of the tools that move money, change a vendor or grant access.
Try it live
Watch AgentShield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Runs the live engine on your text. Nothing is stored, no account needed.
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
The risk
A US manufacturer runs a watsonx Orchestrate procurement agent connected to its ERP through a remote MCP server. The toolkit was imported with every tool on the server because it was faster than picking, and the connection holds a service key with write access. A supplier invoice PDF carries a line of text telling the agent to update the remit-to bank account for that supplier. The pre-invoke guardrail checked the user's chat message, which was harmless. The bank change goes through, and the first person to notice is accounts payable when the real supplier calls about a missed payment.
How AgentShield handles it
Keep IBM's controls for what they do well: the Agentic Control Plane for inventory, runtime policy and content guardrails, pre-invoke and post-invoke plug-ins for message screening and RBAC, human-in-the-loop steps in agentic workflows you design ahead of time, and Enforcement Tracking for audit evidence in watsonx.governance. Then gate the calls that change things outside Orchestrate. Point the remote MCP toolkit URL at an AgentShield gateway endpoint and keep the real credential in the gateway. Each call is checked against per-tool and per-argument policy, a payment, a vendor bank change or a role grant waits for a named approver who is not the requester, injected instructions in documents are flagged, and every decision lands in an audit trail the agent cannot edit.
The controls
The controls that secure which watsonx Orchestrate agent tools run, with whose credentials, and who approves the risky ones.
What watsonx Orchestrate agents do and which IBM control covers each action
watsonx Orchestrate is IBM's platform for building, running and governing AI agents across business systems. Agents are built in the no-code builder, in Langflow, or in code with the Agent Development Kit (ADK). IBM also lets teams import existing LangGraph agents and call external agents over A2A. Each agent gets tools: OpenAPI tools, Python tools, prebuilt catalog integrations, collaborator agents and toolkits imported from remote MCP servers.
The governance layer grew fast in 2026, and most of it is genuinely useful. The useful way to read it is by the moment each control acts: before the agent reasons, after it answers, or at the instant it calls a tool that writes.
| What the agent does | IBM control that applies | When it acts | What it does not decide |
|---|---|---|---|
| Receives a user message | Pre-invoke plug-ins (guardrails, RBAC on collaborators) | Before the agent processes the request | Hostile text that arrives later inside a tool result or a document |
| Returns an answer | Post-invoke plug-ins, Content Guardrails in the control plane | After the agent responds, before the user sees it | Actions the agent already took while producing that answer |
| Calls a tool on a remote MCP server | Tool selection at import, the connection's credentials, runtime policy | At import time, then at runtime per IBM's policy engine | Which argument values a write call may carry, and who besides the requester approves it |
| Runs a multi-step workflow | Human-in-the-loop steps, branching, long-running flows | Where the builder placed the step | Calls an agent decides to make outside a designed workflow |
| Produces evidence for audit | Enforcement Tracking into watsonx.governance, audit logs, Trace Inspector | After the fact | Nothing at runtime, by design |
Read the right-hand column as the scope of each control, not as a list of IBM failures. Orchestrate covers inventory, messages, answers and evidence well. The open question sits at the instant an agent proposes a tool call with specific arguments.
What IBM shipped for watsonx Orchestrate governance in 2026
If your last review of Orchestrate was in 2025, most of this is new. Dates below come from IBM's own announcement pages.
| Capability | IBM date and status | What IBM says it does |
|---|---|---|
| Agentic Control Plane | Introduced June 2026, announced July 2, available on AWS and IBM Cloud | Operational dashboard, agent analytics, policy management, credential health monitoring, an Agent Access overview and Content Guardrails. "Policy management enforces rules at runtime so agent behavior stays within defined boundaries." |
| Enforcement Tracking | Announced August 11, 2026 | Collects agent evaluation metrics and records them "as enforcement evidence within watsonx.governance," then checks them against thresholds set by the business |
| Trace Inspector | GA August 17, 2026 | "shows you the full execution path of an agent run" |
| AI Gateway cross-platform agent discovery | Amazon Bedrock GA August 31, 2026 | Discovers and registers agents built outside Orchestrate; IBM said Azure AI Foundry and Google Vertex AI would follow at the end of September |
| AgentOps agent | GA August 31, 2026 | "generally available for agents native to watsonx Orchestrate," with external LangGraph agents next |
Two things are worth noticing. Enforcement Tracking is evidence, not enforcement at runtime: IBM describes collecting, evaluating and recording metrics, including breaches, not stopping an action. And Content Guardrails act on outputs before they reach users. Neither is designed to hold a single tool call until a second person approves it, and neither claims to be.
Remote MCP toolkits import every tool unless you list them
This is the single setting most worth checking in an Orchestrate tenant. The ADK command for a remote MCP server is orchestrate toolkits add --kind mcp with a URL, a transport and a --tools flag. IBM's documentation describes that flag as "a comma-separated list of tools to import, or * to import all available tools," and the YAML example in the same doc uses the star.
Three more lines in IBM's documentation matter for security:
- Import checks shape, not behavior. "ADK checks only the tool schemas for structural correctness and compatibility with watsonx Orchestrate." Nothing about what a tool does is tested at import.
- Connection secrets reach the server. "Each key and value within the connection will be exposed as environment variables to the mcp server." Whatever key you put in the connection, every imported tool can use.
- OAuth imports use team credentials. IBM says to import OAuth toolkits "using Team credentials," and on-behalf-of SSO connections fail at import. Integration guides from MCP server vendors tell admins to switch back to member credentials afterward. If nobody did, every user's agent acts with one shared identity.
| Import choice | What the agent can do | What we recommend |
|---|---|---|
--tools "*" on a server with read and write tools | Every tool the server exposes today, and any added later on re-import | List read tools explicitly; put write tools in a separate toolkit behind a gate |
| Team credentials left on after import | Every user's agent acts as the service identity | Switch to member credentials where the server supports them |
| Service key with full write scope in a key_value connection | Any imported tool can use the full scope | Narrow the key, or keep it in a gateway the agent never sees |
None of this is an IBM bug. It is the normal shape of MCP, where the server, not the client, decides what a credential allows. Our MCP server security page covers the server side of the same problem.
Guardrail plug-ins screen messages, not individual tool calls
The ADK offers two plug-in types. Pre-invoke plug-ins "operate before the agent processes a request, inspecting and potentially modifying incoming messages," and can accept, reject or reformulate them. They also run RBAC checks on collaborator agents, and a failed check removes that collaborator from the parent agent's list. Post-invoke plug-ins "run after the agent generates a response" and can change the final output, for example masking email addresses.
That design is right for what it targets: abusive input, policy topics, PII in answers, and who may call which collaborator. It does not see the content an agent pulls in mid-run. Indirect prompt injection arrives inside a supplier invoice, a ticket description or a web page that a tool returns, after the pre-invoke check has already passed the user's message. By the time the post-invoke plug-in sees the answer, the write call has run.
IBM's own guardrail example in the ADK docs blocks a message containing a specific lowercase word and masks two others. It is a teaching sample, not a production filter, and IBM presents it that way. Treat plug-ins as the place for your organization's message rules, and add prompt injection protection where tool results and documents enter the agent.
Human-in-the-loop in workflows versus approval on any risky call
IBM lists human-in-the-loop approvals as a developer capability: "Create workflows that pause for human validation, capture context and resume automatically with audit-ready traceability." That works well for processes you can draw in advance, such as a new-hire onboarding flow that pauses for a manager before provisioning laptops.
The gap is agentic behavior outside the drawn path. An agent with a toolkit of twenty tools decides at runtime which one to call and with what arguments. A workflow step only exists where a builder placed it. If the agent reaches a bank-detail update through a tool nobody expected it to use, there is no pause.
| Approval need | Orchestrate workflow step | Per-call gate in front of the tool |
|---|---|---|
| Known process with a fixed approval point | Strong fit, built in | Not needed |
| Agent picks among many tools at runtime | Only where a step was designed | Every call matching a rule pauses, whichever path led to it |
| Approval depends on argument values (amount over 10,000 USD, new bank account, admin role) | Possible with branching logic, built per workflow | One rule on the argument, applied to every agent using the tool |
| Approver must not be the requester | Depends on how the step is configured | Enforced by policy, with the approver's name in the record |
Our page on human approval for AI agents goes deeper on routing that decision to a named approver.
watsonx Orchestrate plans and where the security features sit
IBM publishes list prices for two of three plans. Figures below are from IBM's US pricing page as checked on October 13, 2026; IBM notes prices are indicative and vary by country.
| Plan | Starting price | Monthly active users | Messages per month | Security-relevant extras |
|---|---|---|---|---|
| Essentials | 530 USD per month | 4,000 | Up to 200,000 | Security and access control, control plane |
| Standard | 6,360 USD per month | 40,000 | Up to 2,000,000 | Everything in Essentials at higher limits |
| Premium | Contact IBM | Custom | Custom | Data isolation, dedicated data space, end-to-end protection, HIPAA-ready option |
For US healthcare and other regulated teams, the practical point is that data isolation and the HIPAA-ready option are listed on Premium, not on the published tiers. Enforcement Tracking needs watsonx.governance, which is a separate IBM product. We cover the full cost picture in our watsonx Orchestrate pricing guide, and the healthcare AI agents page covers the BAA side.
watsonx Orchestrate security checklist for US enterprise teams
- Inventory first. Use the Agentic Control Plane and its Agent Access overview to list every agent and the integrations each can reach. Register Bedrock agents through the AI Gateway if you run them.
- Re-import starred toolkits. Find every remote MCP toolkit imported with
*and replace it with an explicit tool list. - Split read and write. Put tools that pay, change vendors, grant roles or send external email in their own toolkit, used only by agents that need them.
- Fix credentials after import. Move OAuth connections back to member credentials where supported, and narrow every key_value service key.
- Write plug-ins for your rules. Pre-invoke for message policy and collaborator RBAC, post-invoke for masking in answers.
- Design approval steps into known workflows. Use human-in-the-loop steps wherever the process has a fixed sign-off.
- Gate the open-ended writes. Route MCP connections that reach finance, vendor, identity or customer systems through a gateway with per-argument rules and an approver who is not the requester.
- Keep evidence outside the agent. Turn on Enforcement Tracking if you own watsonx.governance, and keep an AI agent audit trail the agent cannot edit.
The platform neutral version of this list is our page on AI agent security best practices. If Orchestrate agents work next to ServiceNow or Oracle agents, the ServiceNow AI agents security and Oracle AI Agent Studio security pages cover those platforms.
When to buy nothing, use IBM controls, or add AgentShield
| Your situation | Recommendation | Why |
|---|---|---|
| Agents answer questions and draft, no write tools | Buy nothing. Plug-ins and Content Guardrails | There is no consequential action to gate |
| Write actions only inside designed workflows | Use IBM controls. Human-in-the-loop steps in the workflow | The approval point is known in advance and built in |
| Nobody knows which agents exist across IBM and AWS | Use the Agentic Control Plane and AI Gateway discovery | Inventory before policy |
| Auditors want threshold evidence on agent quality | watsonx.governance with Enforcement Tracking | It produces pass and breach records against your thresholds |
| Agents call MCP tools that pay, change vendors or grant access | Add AgentShield as the gateway behind those toolkits | Rules on arguments, a second approver and evidence outside the tenant |
| Orchestrate, ServiceNow and Bedrock agents share MCP servers | Add AgentShield as one policy point for those servers | One rule set and one audit trail instead of one per platform |
Four of six rows end without a purchase from us. If you are comparing options side by side, our MCP gateway page explains how the gate sits in front of a server, and the AI agent security tools page compares the categories.
FAQ
Common questions about watsonx orchestrate security.
Is watsonx Orchestrate secure?
watsonx Orchestrate ships strong platform controls: role-based access and identity federation, an Agentic Control Plane with runtime policy and Content Guardrails, pre-invoke and post-invoke plug-ins, and audit logs. The open risks are toolkits imported with every tool, shared team credentials after an OAuth import, and write calls on MCP tools that no workflow step pauses.
What security features does watsonx Orchestrate have?
IBM lists security and access control and the control plane on every published plan. The control plane adds policy management, credential health monitoring, an Agent Access overview and Content Guardrails. The ADK adds pre-invoke and post-invoke plug-ins, and Premium adds data isolation, a dedicated data space and a HIPAA-ready option.
How much does watsonx Orchestrate cost?
IBM's US pricing page lists Essentials starting at 530 USD per month with 4,000 monthly active users and up to 200,000 messages, and Standard starting at 6,360 USD per month with 40,000 users and up to 2,000,000 messages. Premium is priced on request. A 30-day trial is available. Prices checked October 13, 2026.
What is the watsonx Orchestrate Agentic Control Plane?
It is IBM's central place to operate and govern agents in Orchestrate, introduced in June 2026. It includes an operational dashboard, agent analytics, policy management that enforces rules at runtime, credential health monitoring, an Agent Access overview of which agents reach which systems, and Content Guardrails that block non-compliant outputs before users see them.
Does watsonx Orchestrate support human-in-the-loop approval?
Yes, inside workflows. IBM describes workflows that pause for human validation, capture context and resume with audit-ready traceability. The approval exists where a builder places the step. Tool calls an agent chooses at runtime outside a designed workflow do not pause unless a separate gate sits in front of the tool.
How does watsonx Orchestrate connect to MCP servers?
Through remote MCP toolkits added with the ADK command orchestrate toolkits add with kind mcp, a URL, a transport of sse or streamable_http, and a tools list. The tools flag takes a comma-separated list or a star for every tool. Connection keys are passed to the MCP server as environment variables.
What is the difference between watsonx Orchestrate and watsonx.governance?
watsonx Orchestrate builds and runs agents and includes the control plane. watsonx.governance is a separate IBM product for AI risk, compliance and evaluation records. Enforcement Tracking connects them by sending Orchestrate agent evaluation metrics into watsonx.governance, where they are checked against business thresholds and stored as evidence.
Does AgentShield work with watsonx Orchestrate?
Yes, for tools on remote MCP servers. Point the toolkit URL at an AgentShield gateway endpoint and keep the real credential in the gateway. Each call is checked against per-tool and per-argument policy, risky calls wait for a named approver who is not the requester, and every decision is logged outside the tenant.
More use cases