Agentic coding in design systems exposes new identity control gaps

At a glance

What this is: This article examines how agentic coding in a design system only becomes reliable when tacit contributor knowledge is converted into executable skills, MCP-backed context, and scoped workflows.

Why it matters: It matters because practitioners adopting AI agents for software delivery need to govern context, ticket qualification, and short-lived access together or they will shift work downstream instead of reducing it.

Context

Agentic coding in a design system is not a generic automation story. It is a governance problem about whether an agent has enough explicit context, permissions, and validation to act on a well-specified workflow without inventing conventions.

For identity teams, the relevant question is how the agent is authorised, what it can discover at runtime, and how long that authorisation lasts. In this article, the design system becomes the proving ground for agentic identity control.

The article shows that the failure mode is not merely bad code quality. When context is missing, the agent makes plausible but incorrect choices, which turns implementation work into review and correction work rather than real automation.

Key questions

Q: What breaks when an agent is given design work without explicit system context?

A: The agent starts guessing conventions, which produces plausible but non-idiomatic output. In practice that means wrong token tiers, incorrect component primitives, and pull requests that compile yet still require substantial human correction. The failure is not syntax, it is loss of system consistency.

Q: Why do scoped agent credentials matter more than broader code-generation capability?

A: Because the control problem is who can act, for how long, and against which resources. If the workflow is bounded, persistent credentials create standing exposure without adding useful capability. Short-lived access keeps the agent within the task window where its actions can still be governed and reviewed.

Q: What are the signs that agentic coding is shifting work downstream instead of saving time?

A: The clearest sign is a high rewrite rate after pull requests are opened. If reviewers are repeatedly correcting conventions, replacing raw elements, or fixing token placement, the agent has not removed work. It has only moved effort from implementation into review and rework.

Q: Who should decide whether a ticket is ready for an agent?

A: A human should decide whether the ticket is specific enough, because readiness is a governance judgment, not a model output. The reviewer should confirm that scope, expected outcome, and conventions are clear before the agent starts. If the ticket still requires interpretation, it is not yet an agent-ready task.

Technical breakdown

Why cold-start agents make plausible but wrong design choices

A general-purpose coding agent can read a ticket and navigate a repository, but that does not mean it understands the design system's internal conventions. In this article, the agent guessed token tiers, reached for raw HTML elements, and produced code that compiled but was not idiomatic. That is a context problem, not a code-generation problem. The agent lacked the system-specific rules that human contributors keep in memory: directory structure, component primitives, naming conventions, and review expectations. Without those, the model optimises for local plausibility rather than system consistency.

Practical implication: treat design-system context as an authorised input surface and not as optional background reading.

Why MCP-backed context changes agent identity governance

The article shows the value of exposing authoritative design system information through MCP so the agent can ask what exists, how it should be used, and which patterns are appropriate at runtime. That matters because the agent is no longer relying on stale copied context or guesswork. Instead, its actions are constrained by a governed source of truth. For identity practitioners, this is the same pattern seen in workload and service access: the actor should query an authoritative control point rather than infer permissions from whatever it can scrape.

Practical implication: bind agent workflows to authoritative context services instead of leaving them to infer rules from repository content alone.

Why scoped agent credentials belong in the control model

The article's most important security point is that the design system MCP disconnects after a fixed window, which makes persistent agent credentials a liability. That is a standard identity control lesson applied to an autonomous workflow: if the task is bounded, the access should be bounded too. Short-lived, scoped credentials reduce the blast radius if the agent is misdirected or over-queries the system. The article also makes clear that human ticket qualification remains part of the control path, because the agent should only enter the workflow after a person has deemed the work ready.

Practical implication: issue short-lived access for agent workflows and keep a human qualification gate before execution begins.

NHI Mgmt Group analysis

Agentic coding exposes a context-authorisation gap, not a model-quality gap: the decisive variable is whether the agent receives explicit, executable system knowledge before it is allowed to act. When that knowledge is missing, the agent fills in the blanks with plausible guesses that break design-system consistency. The implication is that agent governance starts with context packaging, not code review.

Short-lived scoped access is the right baseline for agent workflows: the article's fixed-window MCP disconnect shows that persistent agent credentials create unnecessary standing exposure. Agent access should exist only for the task window in which the system can still validate intent and output. That is a core NHI control principle applied to autonomous tooling.

Ticket qualification is now an identity control point: the human who labels a ticket as ready is not just approving work, they are authorising the agent's entry into a governed workflow. That makes the intake step part of access governance, because it determines which tasks are eligible for machine execution. Practitioners should treat work-item readiness as a policy boundary, not a project-management convenience.

Design systems are becoming the best proving ground for agent identity controls: they have explicit conventions, predictable outputs, and fast feedback loops, which makes failures visible early. That is why the article is important beyond design tooling. It shows where agentic identity governance is likely to mature first: in bounded environments where context, access scope, and validation can all be made explicit.

The real control gap is stale tacit knowledge encoded as implicit privilege: human contributors know which primitives, tokens, and patterns are acceptable, but the agent does not inherit that knowledge automatically. When those rules live only in people's heads, the system effectively grants the agent implicit latitude to improvise. The practitioner conclusion is clear: if a rule matters, it must be explicit enough to govern machine execution.

From our research library:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: AI Agent Authorisation Guide

What this signals

Scoped context will become the control plane for agentic software delivery: the article shows that agents perform well only when the task space is narrow, the rules are explicit, and the runtime context is authoritative. That pattern will matter far beyond design systems as more teams move agents into code and workflow execution.

A practical identity takeaway is that agent authorisation should be tied to task readiness and revoked when the workflow ends. In NHIMG terms, the issue is not whether the agent can generate output, but whether its access is bounded tightly enough that a mistaken action cannot become a persistent governance problem.

For practitioners

• Define skills for atomic contributor workflows Break design-system work into narrow skills such as scaffolding a component, writing Storybook stories, and handling CI failures so the agent executes known steps instead of improvising.
• Expose authoritative context through MCP Wrap the component registry, token model, or Figma library in a runtime context service so the agent can query approved patterns instead of inferring them from code.
• Keep a human qualification gate Require a reviewer to label tickets as ready before the agent can work, and reject ambiguous items that a new contributor could not implement from the description alone.
• Use short-lived scoped credentials Limit agent access to the minimum task window and revoke credentials after the workflow completes, especially where the agent can reach code, design tokens, or CI systems.
• Make uncertainty visible in every PR Require the agent to flag uncertain token tiers, component choices, or pattern matches in the pull request description so reviewers can validate the exact decision points quickly.

Key takeaways

• Agentic coding in design systems works only when tacit contributor knowledge is converted into explicit, executable instructions that the agent can actually follow.
• The main failure mode is not broken syntax but plausible output that violates component conventions, token hierarchy, and review expectations.
• Short-lived scoped access and a human qualification gate are the controls that keep agent workflows from turning automation into downstream rework.

Key terms

• Agentic Context: The environmental, organisational, and operational information an AI agent uses to decide what it is looking at and what action is appropriate. When context is incomplete or wrong, the agent can behave rationally inside the wrong frame, which turns ordinary access into unsafe execution.
• Human Qualification Gate: A human approval step that decides whether work is ready for machine execution. In this article's context, the gate prevents ambiguous tickets from entering the agent workflow and acts as an identity boundary, because it determines when the agent is authorised to act.
• Scoped Agent Identity: Scoped agent identity is a non-human identity assigned to an AI system or agent with explicit limits on what it may access and do. The scope must be narrower than a human session because agents can execute independently, interact with tools, and persist across workflows.
• Executable Skill: A machine-readable workflow instruction that tells an agent what to do, in what order, and with which commands or paths. Unlike ordinary documentation, an executable skill is designed to be run, audited, and updated alongside the system it describes.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.