MCP gives agents a standard interface. It doesn't give them security by default.
MCP standardizes how an agent talks to a tool, and its own spec does define an OAuth-based authorization flow — but that flow is optional, many servers skip it, and even a compliant one only answers "can this client reach this server," not "should this specific action be approved" or "log this decision." Tool-level permissions, call-level audit logging, and approval policy still have to be built around it. Vendors selling "MCP integration" rarely address any of that.
Who this is for
Security and compliance reviewers evaluating an MCP-based AI integration who need to know what's actually enforced — not just what protocol it technically supports.
What you get
An MCP integration with scoped permissions per tool, call-level audit logging, and policy enforcement — reviewed the way your security team actually reviews a system, not glossed over as "it's just an API."
Inputs and systems
Systems in scope
Any MCP server your agent needs to call — a vendor-hosted server (Salesforce, SAP, ServiceNow) or a custom internal one — plus your identity provider for the OAuth flow, when the server implements it.
Prerequisite access
Read-only access to the MCP server's tool catalog and your identity provider's OAuth configuration, provisioned before day one — no write access requested up front.
Sandbox vs. production
The permission model and audit logging are designed and tested against a sandbox or staging MCP server first. Production write scopes are enabled only after your team reviews the policy.
What can be read or changed
Exactly the tools you allow-list, nothing implicit — an agent scoped to read invoices never inherits write access to your GL just because both live behind the same MCP server.
The workflow
01: Tool call requested
The agent requests a call against an allow-listed MCP server tool — anything not on the allow-list is rejected before it reaches the server.
02: Scope check
The request is checked against that tool's own permission boundary — read vs. write, which records, which fields.
03: Policy / approval
A write action isn't auto-approved by default. It routes to whatever approval boundary you set — auto-execute inside a tight boundary, or a human decision for anything wider.
04: Execution boundary enforced
The call executes only within the allow-listed scope. Anything outside it is blocked outright, not silently downgraded or best-effort attempted.
05: Verified, logged result
Input, output, and which policy check ran are logged at call level — reviewable evidence of what actually happened, not just what was requested.
Why this is real, not a pitch deck
Scoped by design
Every MCP integration Tioga builds allow-lists exactly which tools an agent can call — an agent that can read invoices doesn't automatically get write access to your GL.
Every MCP integration on this site is real
See the MCP page for the actual pattern — before/after comparisons and live tool-calling, not a diagram.
Built by an operator, not just a security vendor
The founder's background managing real ERP/CRM/HR systems means the permission boundaries are scoped around how these systems actually get misused, not a generic checklist.
No "trust the vendor" black box
Call-level audit logging — input, output, and which policy check ran — is the standard every integration is built around, not an optional add-on you have to ask for.
Engagements
Every engagement starts with a 5-day Discovery Sprint ($5,000 flat, prototype included) that scopes the work before any larger commitment — credited toward the price below if you move forward.
Not ready to scope an engagement? Free ERP Agent-Readiness Checklist →AI Operations Assessment
The right starting point to scope an MCP security review or a new integration's permission model — maps what needs access to what, ranked by risk and feasibility.
$10–15K
2–3 weeks
Legacy System AI Augmentation
Add a governed MCP integration to your existing systems with scoped permissions and audit logging built in from the start.
$40–100K
8–16 weeks
Questions
Is MCP itself secure?+
MCP's spec defines an optional, OAuth-based authorization flow — but it stops at whether a client can reach a server at all. It doesn't give you tool-level business permissions or call-level audit logging. Those have to be built around it, which is exactly what this engagement scopes.
What does "scoped permissions" mean in practice?+
Each tool an agent can call is explicitly allow-listed with its own permission boundary — an agent that can read invoices doesn't automatically get write access to your GL, for example.
Do you log every tool call?+
Yes — call-level audit logging with input and output is the standard Tioga builds every MCP integration around, not an optional add-on.
We already have an MCP integration built by another vendor — can you review it?+
Yes, a security review of an existing MCP integration is a fit for the Discovery Sprint, scoped to audit rather than build.