TL;DR: AI can help normalize tokens, variants, and usage guidance when it operates on real file context rather than abstract prompts, according to Lasso Security. The governance lesson is that contextual access must be observable and bounded, or the same tooling that improves consistency can expose product architecture and expand trust assumptions.
At a glance
What this is: This is an analysis of using MCP inside Figma to let AI inspect live design-system structure and improve token, component, and usage consistency.
Why it matters: It matters because IAM and security teams increasingly need to govern contextual tool access, not just static permissions, when AI is allowed to act on proprietary product assets.
Context
Design systems often fail when tokens, components, and usage guidance evolve separately instead of as one governed structure. The article's core claim is that AI can help normalise that structure when it operates on real file context inside Figma through MCP, rather than on abstract prompts.
That shifts the governance problem from generic AI assistance to contextual access control. Once an AI tool can see component hierarchies, variant properties, token definitions, and naming conventions, the issue becomes whether that access is observable, bounded, and aligned to the work being done.
Key questions
Q: How should security teams govern AI agent access to design files in MCP-based workflows?
A: 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.
Q: Why does contextual AI increase governance risk in design systems?
A: Because the model is no longer working from synthetic prompts. It can inspect real component structures, tokens, naming conventions, and layer hierarchy, which improves accuracy but also exposes architecture that teams may not intend to reveal. Risk rises when that visibility is broader than the task requires.
Q: What are the signs that a design system needs tighter token governance?
A: Look for redundant colour values, spacing increments that no longer follow a base rhythm, radius values that do not align to the scale, and inconsistent naming that makes implementation ambiguous. Those symptoms show that inconsistency is being encoded at the foundation and will spread into components.
Q: What should teams do when AI starts consolidating component variants?
A: Require explicit rules for legitimate states before consolidation begins. If loading, disabled, or alternate behaviours are not defined clearly, the AI will compress structure in ways that may hide real product differences. The right control is a state model that governs when a variant is actually justified.
Technical breakdown
How MCP changes AI behaviour inside a design file
Model Context Protocol lets an AI tool query live application context instead of generating from a blank prompt. In this case, that means the model can inspect Figma component structures, variant properties, token definitions, naming conventions, style mappings, and layer hierarchy. The technical shift is from invention to inspection: the AI is not asked to imagine a design system, but to reason over the one already present in the file. That makes outputs more structurally grounded, but it also means the tool can reveal far more of the product architecture than a normal prompt exchange.
Practical implication: Treat MCP connections as governed access paths to production design assets, not as generic AI integrations.
Why token architecture is the first control point
Tokens are the foundation layer that makes scale possible because they define repeated values such as colour, spacing, radius, elevation, and semantic state mappings. When token values drift, inconsistency spreads into every dependent component and usage rule. The article shows AI flagging redundant colours, broken spacing rhythm, misaligned radius values, and naming inconsistencies by comparing token data inside the file. That is useful because token architecture is where structural drift becomes visible before it hardens into component sprawl.
Practical implication: Normalise token definitions before expanding the component surface or writing usage guidance.
Why contextual visibility improves component governance
Once the token layer is stable, the same contextual access lets AI compare variant matrices across buttons, inputs, cards, and navigation elements. That exposes duplicated states, overlapping configurations, and inconsistent loading or disabled behaviour. In governance terms, variants stop being ad hoc design choices and become controlled contracts. The article's point is not that AI should decide aesthetics, but that it can surface where structural overlap is already creating maintenance debt and implementation ambiguity.
Practical implication: Use contextual comparison to collapse redundant variants and define explicit state rules across components.
Threat narrative
Attacker objective: The objective is to obtain broad, context-rich visibility into proprietary product architecture through a trusted AI workflow.
- Entry occurs when an AI tool is granted MCP access to a live Figma file and can read real tokens, components, naming conventions, and hierarchy.
- Credential access and scope emerge through that contextual connection, because the tool can inspect proprietary product architecture rather than isolated prompts.
- Impact follows when that visibility is not bounded or observable, allowing contextual access to become uncontrolled access to sensitive design-system intelligence.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Context-aware AI governance is now an access problem, not just a productivity problem. When an AI system can inspect live design files, the governance question is no longer whether it can help teams work faster. The real question is what file context it is allowed to see, how that access is observed, and whether the resulting visibility is proportionate to the task. Practitioners should treat MCP connections as governed pathways into proprietary architecture, not as harmless assistants.
Token architecture becomes the control plane for design-system coherence. The article shows that token drift, redundant values, and inconsistent naming create the conditions for component sprawl later. That is why the governance issue starts at the foundation layer, before visible UI complexity accumulates. Teams that cannot normalise tokens early will keep paying for inconsistency in every downstream component decision.
Real-context AI changes the trust model for design operations. Without MCP, AI can only suggest patterns. With MCP, it can inspect actual structures and support refactoring, but that also means the boundary between insight and exposure narrows. The implication is that design-system governance now needs a clear model for contextual data access, not just a policy for AI use.
Design-system governance and identity governance are converging around bounded delegation. The same pattern appears whenever a tool is allowed to act within a real operational environment: value comes from context, but risk comes from over-broad access. For identity practitioners, the lesson is that any workflow granting AI real environment visibility needs lifecycle controls, observability, and explicit limits on what the tool can infer from that context.
Embedded audit behaviour only works if the audit path itself is governed. The article describes AI as a layer that continuously reinforces consistency, but audit-like capability is useful only when its scope is constrained and reviewable. In other words, continuous analysis is not a substitute for governance. Practitioners should assume that contextual AI will surface structural debt, then ensure the access path cannot quietly exceed the purpose for which it was granted.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Context-aware AI governance: The governance problem shifts when an assistant can inspect live product files, because access to structure is itself sensitive. Teams need to decide which metadata, hierarchy, and naming context an AI workflow can see before they let it contribute to refactoring or documentation.
The most durable control in this pattern is bounded delegation. If contextual access is observable and purpose-limited, AI can help reinforce consistency; if not, the same integration becomes a quiet path to architecture exposure and trust expansion. This is why design workflows now need the same discipline that identity teams apply to other high-value operational contexts.
MCP configurations are already exposing secrets at scale, with 24,008 unique secrets exposed in MCP configuration files in 2025 alone, according to the State of Secrets Sprawl 2026. That figure is a warning that contextual tooling needs governance before convenience turns into leakage.
For practitioners
- Define MCP access boundaries for design tools Limit which Figma files, branches, and component libraries an AI assistant can inspect, and separate exploratory read access from any workflow that can modify source design assets.
- Treat tokens as governed foundations Standardise semantic colour, spacing, radius, elevation, and surface tokens before allowing AI-driven refactoring so that the model reinforces a stable system instead of amplifying drift.
- Constrain contextual exposure in live environments Route AI access through an observable gateway, log file-level interactions, and review what structural metadata the tool can infer from component hierarchy and naming conventions.
- Convert variant sprawl into explicit state rules Document which loading, disabled, and alternate states are legitimate so that AI can consolidate overlapping variants without expanding the library on every edge case.
Key takeaways
- AI-assisted design systems create a governance problem as soon as the tool is allowed to inspect real file context rather than synthetic prompts.
- Token drift, variant sprawl, and naming inconsistency are early signals that the design system needs tighter structural control.
- The practical response is to bound MCP access, normalise the foundation layer first, and make contextual visibility observable.
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, OWASP API Security Top 10 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 | ASI03 — Identity & Privilege Abuse | AI access to live Figma context hinges on delegated authority and scope control. |
| Recommendation — Apply ASI03 to bound what contextual data an AI assistant can inspect and modify inside live design files. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | MCP-style integrations depend on strong authentication and scoped access to live resources. |
| Recommendation — Validate authentication and authorization on MCP integrations before exposing proprietary design assets. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about governing AI use inside an operational workflow. |
| Recommendation — Use GOVERN to assign accountability, scope, and review for AI access to production design context. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Contextual AI access must be limited to the permissions needed for the design task. |
| Recommendation — Apply PR.AA-05 to restrict AI access to the smallest viable set of files, tokens, and components. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | MCP-connected tools behave like third-party NHIs inside a design environment and can expose assets if mis-governed. |
| Recommendation — Review MCP-connected assistants as third-party NHIs and revoke any unnecessary file-level access. | ||
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- Contextual Access Control: Contextual access control changes access decisions based on factors such as device posture, application risk, location, or data sensitivity. In cloud security, it helps move access policy from static entitlements toward decisions that reflect the actual conditions of use.
- Design Tokens: Reusable values that define visual and behavioural consistency across a design system, such as colour, spacing, typography, and elevation. They act as the stable layer that components depend on, so drift in tokens spreads quickly into the entire system and becomes harder to correct once automation starts amplifying it.
- Variant Matrix: The structured set of component states and property combinations used to manage design-system behaviour. In AI-assisted workflows, variant matrices matter because they reveal where states overlap, where duplication exists, and where governance needs clear rules before more options are added.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org