Design Tools Are Now an AI Agent Runtime Surface
Figma, Canva, and comparable design platforms have quietly become execution environments for AI agents. Plugins, REST and Connect APIs, and Model Context Protocol (MCP) connections all give automated agents a path to read, modify, and create design files, brand assets, and project data. That makes these platforms functionally equivalent to any other enterprise software that AI agents now operate inside: a runtime that needs identity, permission scoping, and logging, not just user account controls.
The practical challenge is that these three integration points did not emerge from a single, unified authorization model. Each was built for a different purpose at a different time, and each now needs to be governed on its own terms while still rolling up into a consistent security posture.
Three Integration Patterns, Three Authorization Models
Plugin and app SDKs run as sandboxed third-party code inside the design tool itself. Access is granted by the individual user at install time, with network and file permissions bundled into a single approval rather than scoped incrementally.
REST and Connect APIs provide OAuth2-authenticated programmatic access to files, projects, and brand assets. This is the most mature of the three models, but OAuth2 scopes are only as protective as the scopes an organization actually enforces at grant time.
MCP connections give agents direct access to design context, but authorization maturity varies significantly by implementation. Some MCP servers and clients implement OAuth 2.1 authorization; others rely on implicit trust between the agent and the connected tool.
Where the Governance Gaps Appear
Because each integration pattern was adopted independently, most organizations lack a single answer to a simple question: which AI-enabled plugins, apps, or MCP connections currently hold access to Figma or Canva files, and under what scopes. Permissions are frequently granted per user, at the point of installation, with no centralized review or revocation process.
Audit logging compounds the problem. File-level or account-level activity logs typically do not distinguish an AI agent's individual actions from a human user's actions, which leaves compliance and incident response teams without the evidence trail they need when an agent, rather than a person, made a change.
Applying Runtime Governance to Design Tool Agents
Treating design tools as an agent runtime means applying the same four controls used to govern AI agents anywhere else in the enterprise.
-
01
Verifiable agent identity
Every plugin, app, or MCP connection with access to design files should be attributable to a distinct, verifiable identity, separate from the human user who authorized it.
-
02
Least-privilege permission scopes
OAuth scopes for API and Connect integrations should be enforced at the minimum level required for each agent's function, rather than accepted as broad, bundled grants.
-
03
Explicit policy enforcement
MCP connections should be evaluated for whether they implement OAuth 2.1 authorization or rely on implicit trust, and policy should require the former before production access is granted.
-
04
Agent-level audit logging
Audit trails should record individual agent actions on design files and connected storage, not just general file or account activity, so they can serve as compliance evidence.
Centralize approval and revocation
Replace per-user plugin installation with a central process for approving and revoking AI plugin or app permissions, so access can be reviewed and withdrawn without depending on individual users to manage it.