When an AI agent gains the ability to invoke internal interfaces, the information security team immediately asks three questions: who issued the access, how to revoke it, and how to reconstruct an incident a month later. The answers come not from traffic inspection but from operation-level access management, a concept previously outlined in the article on MCP security for AI agents.
Standard interface controls apply: each tool is treated as a distinct operation rather than an entire system; operations are selected at publication time; every agent receives its own application with dedicated keys; limits are set on the subscription; revoking a single subscription does not affect the overall configuration; the log records the initiator; and access is granted by the resource owner after approval.
The material examines the mechanics on NEOMSA APIM MCP servers and provides a checklist of 15 checks that works regardless of the products in the environment. Technical details follow the Model Context Protocol Specification 2026–07-28.
Why MCP Is No Longer Experimental
In December 2025 Anthropic transferred MCP to the Agentic AI Foundation under the Linux Foundation. At that time the protocol recorded 97 million SDK downloads per month and more than 10,000 public servers. By July 2026 monthly downloads approached half a billion, with TypeScript and Python SDKs together exceeding one billion. MCP has become the de-facto standard for connecting AI agents to corporate systems.
Once tools include customer records, transaction history or limit calculations, the integration falls under corporate security responsibility. The article describes a typical zoned network where one support agent reads customer data and calculates limits while another helps staff modify those limits. Prototypes are built in a week, yet production rollout is blocked by architectural security requirements that become expensive to retrofit later.
Why Classic Traffic Filters Fail
Traffic inspection validates syntax, schema and absence of injections, but cannot decide whether the calling agent is authorized for that specific operation. Authentication confirms identity; authorization at the tool level is missing when an application receives overly broad rights. The two layers therefore address separate concerns and must both be enforced.
Publishing Tools: From API to MCP Operations
Agents do not call systems; they invoke named tools with strict data contracts. In NEOMSA APIM an MCP server can be created by importing an OpenAPI definition and selecting only the required operations, by reusing an already published API with its existing authentication and rate-limit settings, or by proxying an upstream MCP server. Only the chosen operations appear in tools/list; any attempt to call an unlisted tool by name is rejected at the gateway.
The example publishes two servers and three tools: customers_get (scope customers:read), limits_calculate (scope limits:calculate) and limits_update (scope limits:write). Tool descriptions are also security controls; vague names or loose schemas allow models to guess parameters, while poisoned descriptions can inject hidden instructions. Every change therefore requires review and versioning.
Issuing and Scoping Access
Before a token is issued, the resource owner must approve a subscription that lists the application, purpose, allowed operations, limits and review date. Each agent is represented by its own application with consumer key and secret. Multiple subscriptions with different plans can be attached to the same application, separating read and write privileges. Scopes are enforced at token issuance so that an application without the required role never receives a token that would allow the operation.
Identity propagation is handled either by a trusted header added after authentication or by OAuth 2.0 token exchange that preserves the delegation chain. Passing the original user token unchanged violates audience checks and is architecturally incorrect.
Rate Limits and Business Validation
Rate limits must be applied at the subscription level; otherwise a looping agent can exhaust shared quotas and affect other consumers. Final authorization decisions remain with the target service, which validates both the agent’s rights and the specific business object, preventing classic BOLA/IDOR issues and ensuring non-duplication through idempotency checks.
