MCP is the transport and permission layer that connects an AI application to approved tools and data sources. An agent skill is the procedural layer that tells the agent how to complete a specific compliance task, such as analysing a policy or creating a verification workflow. In practice, MCP exposes what the agent may use, while the skill shapes how it should work.
Why MCP and an agent skill are not the same control
MCP and an agent skill sit at different layers of the system, so they solve different problems. MCP is the plumbing for approved access, it governs which tools and data sources an AI application can reach. An agent skill is the procedure layer, it tells the agent how to carry out a specific compliance task once access exists. That distinction matters because compliance automation fails differently when transport is confused with task logic.
For practitioners, the practical question is whether a control boundary, approval gate, or audit requirement belongs in the connection layer or inside the task workflow. If it belongs in MCP, the concern is what the agent may invoke. If it belongs in a skill, the concern is how the agent should reason, sequence checks, or produce evidence. The OWASP OWASP Top 10 for Agentic Applications 2026 is useful here because it treats tool misuse, privilege abuse and agent behaviour as distinct risk surfaces, not one merged category.
In practice, teams get into trouble when they assume “the agent is approved” means both the connection and the workflow are safe.
How the two layers work together in compliance automation
MCP is the access contract. It is where an AI application connects to an approved compliance repository, policy engine, case system, or evidence store through defined permissions. Good MCP design limits tool scope, narrows the data surface, and makes access reviewable. That is especially important in compliance automation because the agent often needs read access to sensitive artefacts, but not broad write access to surrounding systems.
An agent skill is the operational playbook. It describes how to complete one compliance job, such as checking a policy against a control set, assembling evidence for an audit request, or drafting a remediation workflow. The skill may define ordered steps, thresholds, exceptions, output format, and human review points. The skill is what gives the automation repeatability, while MCP gives it controlled reach.
- MCP answers: which sources, tools, or actions are available?
- Skill answers: what sequence should the agent follow to complete the task correctly?
- MCP should change less often than the skill when you refine process logic.
- The skill should change when the compliance method changes, even if the toolset stays the same.
That separation is why compliance teams should treat tool authorisation and process design as related but not interchangeable controls. A well-scoped skill cannot rescue over-broad tool access, and tightly scoped MCP permissions do not guarantee that the agent will execute the task in a compliant order. The NIST AI Risk Management Framework is relevant because it pushes organisations to govern AI behaviour, not just AI access. These controls tend to break down when teams let the skill write or approve records directly in production without a separate human review path.
Common variations and edge cases in real deployments
Tighter separation between MCP and skills often improves auditability, but it also increases operational overhead, because teams must govern both permissions and procedures. The trade-off is worth it when compliance evidence must be defensible, repeatable, and easy to trace, but it can be overkill for low-risk, read-only workflows.
One common edge case is an agent skill that becomes too powerful because it inherits whatever MCP exposes by default. Another is the reverse, where MCP is so restricted that the skill cannot complete the task without manual intervention at every step. Best practice is evolving, but the rule of thumb is simple: keep MCP narrow and explicit, then make the skill do the reasoning and sequencing inside that boundary.
Compliance automation also changes shape when the workflow touches regulated evidence, legal holds, or attestation steps. In those cases, the skill should include clear stop conditions and escalation points, while MCP should only expose the minimum systems needed to gather or verify evidence. The most relevant comparison is not “which is smarter?”, but “which layer is accountable for access, and which layer is accountable for task execution?”
Current guidance suggests that teams should avoid using a skill as a hidden policy engine. If a control decision needs formal approval or a traceable exception, it should be visible in the workflow, not buried in the prompt or procedure.
Risk and Threat Considerations
Compliance automation introduces two distinct risk classes, over-broad access through MCP and unsafe execution through the skill. The first creates exposure if the agent can reach more systems or data than the task requires. The second creates process risk if the agent follows the wrong sequence, skips a validation step, or generates evidence that looks complete but is not actually trustworthy.
Failure mechanism: When MCP permissions are too broad, an attacker or faulty workflow can abuse approved access to retrieve sensitive data, alter evidence, or pivot into adjacent systems. When the skill is poorly designed, the agent can be induced to over-collect, misclassify, or mishandle compliance artefacts, especially when task instructions are ambiguous or the workflow accepts unverified outputs.
Impact: The result can be audit failure, evidence contamination, unauthorised data exposure, or a false sense of compliance that survives until review time. In more serious cases, the automation can become a repeatable path for misuse because both access and procedure are encoded and reused at scale.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 — Tool Misuse and Over-Privileged Actions | MCP tool access and agent actions map directly to over-privileged agent behaviour. |
| A6 — Agent Identity and Access | Compliance automation depends on how the agent is authenticated and authorised to act. | |
| A7 — Agent Memory and State Integrity | Compliance skills rely on stable procedural state and trustworthy outputs across steps. | |
| Recommendation — Limit agent tool scope and require explicit approvals for high-impact actions. Bind each agent to least-privilege access and review its permissions regularly. Protect agent state and validate intermediate outputs before they drive compliance decisions. | ||
| NIST AI RMF | GOVERN — Govern AI systems with documented roles, accountability, and oversight | Compliance automation needs accountable governance for access and task execution. |
| MAP — Map AI risks, uses, and context | MCP and skills should be mapped separately because they represent different AI risk surfaces. | |
| MEASURE — Measure and monitor AI performance and risk | Compliance automation needs monitoring for access scope and task correctness. | |
| Recommendation — Assign clear ownership for AI access, workflow design, and exception approval. Document which risks belong to tool access and which belong to workflow behaviour. Track permission scope, failed workflow steps, and abnormal agent actions over time. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | MCP is an access-control layer that should be governed with least privilege. |
| PR.DS — Data Security | Compliance workflows handle sensitive evidence and records that need controlled exposure. | |
| DE.CM — Continuous Monitoring | Agent tool use and workflow execution need monitoring to detect abuse or drift. | |
| Recommendation — Restrict agent access to the minimum approved tools and data sources. Protect compliance evidence with access limits and approved handling rules. Monitor agent actions and alert on unusual access or workflow deviations. | ||
Practitioner Guidance
What to prioritise: Separate the access review from the workflow review. MCP should be evaluated for least privilege, approved tool scope, and traceable permissions; the skill should be evaluated for task sequence, decision points, and exception handling.
Decision rule: If the issue is “can the agent reach it?”, fix MCP. If the issue is “will the agent do the task correctly?”, fix the skill. If both are weak, treat the workflow as unsafe until both layers are corrected.
What to verify: Confirm that the skill cannot silently widen access, bypass review, or write evidence into systems that the MCP layer was meant to keep read-only. In compliance use cases, that separation is what makes the output defensible.
Practitioner takeaway: The cleanest compliance automation design is narrow access plus explicit procedure, because governance fails fastest when permission and execution are bundled into one opaque layer.
Related resources from NHI Mgmt Group
- What is the difference between securing an AI model and securing an MCP-enabled agent?
- What is the difference between controlling user access and controlling AI-agent access in MCP deployments?
- What is the difference between standard tool integration and MCP-based AI agent access?
- What is the difference between an MCP server and an AI agent built on top of it?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
