Security teams should treat design systems as sensitive intellectual property and place MCP access behind policy enforcement. Limit agents to the smallest file and frame scope, inspect every tool call for embedded secrets or customer data, and block or redact sensitive content before it reaches the model. Pair access controls with per call audit logging so teams can prove what was read and why.
Why This Matters for Security Teams
AI agents that can read design files through MCP are not just another application user. They are goal-driven workloads that can chain tool calls, pull context from multiple sources, and expose sensitive intellectual property in ways a human reviewer may never anticipate. That is why static role grants are too coarse for this problem, especially when agents move from one frame to the next based on runtime intent. The risk is not limited to source code. Design systems often contain product plans, customer details, credentials, and unreleased assets.
Current guidance suggests treating agent access as an NHI governance problem with AI-specific controls layered on top. Research from Astrix Security found that only 18% of MCP server deployments implement any form of access scoping for tool permissions, which shows how often the control gap starts at the protocol boundary. That aligns with broader concerns in the OWASP Agentic AI Top 10, where overbroad tool access and data leakage are recurring failure modes. In practice, many security teams discover the problem only after an agent has already copied sensitive frames into a downstream workflow or exposed them in a prompt trace.
How It Works in Practice
Governance works best when the MCP server is treated as a policy enforcement point rather than a passive data pipe. The agent should not receive open-ended file access. Instead, authorisation should be evaluated at request time based on the task, the specific frame or folder requested, the sensitivity label of the asset, and the identity of the workload making the call. That is closer to intent-based access than traditional RBAC.
In practical terms, security teams should combine four controls:
- Use workload identity so the agent proves what it is before it can request design resources, not just what token it holds.
- Issue just-in-time, short-lived credentials for a narrowly defined task and revoke them when the task ends.
- Inspect tool output for embedded secrets, customer data, or proprietary content before the model receives it.
- Log each read action with enough detail to show which file, frame, and policy decision were involved.
This approach maps well to NIST AI Risk Management Framework expectations for accountability, and it is reinforced by CSA MAESTRO agentic AI threat modeling framework, which emphasizes runtime risk controls for tool-using agents. NHIMG research on Analysis of Claude Code Security also reflects a common lesson: once an agent can traverse design assets and supporting context, the real security boundary becomes policy at the moment of access, not repository membership. These controls tend to break down when MCP is connected to legacy design repositories that lack file-level labels or when teams allow long-lived tokens to persist across multiple agent tasks.
Common Variations and Edge Cases
Tighter design-file controls often increase workflow friction, so organisations need to balance content protection against designer productivity and automation speed. That tradeoff becomes sharper in fast-moving product teams, where agents may need temporary access to many small assets across a shared workspace.
Best practice is evolving for a few edge cases. When an agent only needs to extract metadata, read-only access may be sufficient if content redaction is enforced at the server. When design files are stored in systems that do not support fine-grained entitlements, compensating controls such as proxy-based filtering, per-frame export rules, and stronger audit review become necessary. For multi-agent pipelines, the risk is higher because one agent may fetch the file while another summarizes it, making it harder to prove where sensitive material leaked. The broader agentic attack surface described in OWASP NHI Top 10 and the runtime threat perspective in NIST Cybersecurity Framework 2.0 both point to the same operational reality: if the policy layer cannot understand the task, the sensitivity of the asset, and the agent’s current context, access control will eventually be bypassed by normal workflow usage rather than by an obvious attack.
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, CSA MAESTRO and OWASP Non-Human Identity 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 | A4 | Agent tool access must be constrained to prevent data exfiltration. |
| CSA MAESTRO | TA-2 | MAESTRO covers runtime threat analysis for tool-using agents. |
| NIST AI RMF | GOVERN | AI RMF governance fits accountability for agent access decisions. |
| OWASP Non-Human Identity Top 10 | NHI-03 | NHI credential lifecycle controls apply to agent tokens used in MCP. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control is central to design-file governance. |
Restrict agent tool scope and block sensitive design content at the MCP boundary.
Related resources from NHI Mgmt Group
- How should security teams govern API keys used for generative AI access?
- How should security teams govern AI agent identities in MCP workflows?
- How should security teams govern AI agent audit logging in MCP workflows?
- How should security teams govern non-human identities that have persistent access?
