I learned about the principle of least privilege a few months ago, while reading about AI agent security. Every program and user should operate with the least amount of authority necessary to complete the job — no broader access than the task requires, and no wider permissions than the action warrants. Saltzer and Schroeder formalised it in 1975, and the security world has been building on it ever since.
I kept thinking about it in the context of design system governance: we've spent years asking whether teams trust their design system, whether contributors follow the rules, and whether the governance model works. But we've spent less time asking what the system itself is allowed to do. And that's what's becoming urgent.
The question most teams are asking right now is "can we trust this agent?". Unfortunately, agents don't have trustworthiness ratings you can look up, but what you can evaluate is the action. A lint fix and a component API change are not the same kind of decision. Treating the answer as "yes, this agent can do things" or "no, this agent can't" misses the point entirely. What you actually need to answer is: what should this agent be allowed to do without asking, and what should always need a human?
I've been writing about the accountability gap that opens up when agents start contributing to design systems — who owns the output when nobody made a deliberate choice? That question gets more concrete when agents aren't just suggesting things, but actually changing them. The accountability gap turns into a permissions problem, and the principle of least privilege is, as far as I can tell, the most useful lens we have.
So you assign actions to tiers. Not agents, actions.
How confident can you be that the agent's analysis is correct, and how bad is it if the agent is wrong? Lint violations, accessibility label corrections, documentation typos — these are deterministic rules with low consequence, so they auto-merge. Token value updates and component description changes go to a draft PR, because the agent might be right that something is inconsistent, but it can't reason about what that change means across every consuming product. Component API changes, deprecations, governance decisions — suggest only; human signs off every time. Not because the agent can't spot the problem, but because deciding what to do about it requires context the agent doesn't have: who depends on this, what the roadmap says, what you're willing to break next release.
The tier is determined by the cost of being wrong.
Token values encode visual decisions that teams across a whole product have aligned on. Changing one without review doesn't just modify a file; it modifies a shared understanding. I wrote about tokens as contracts between design and development in Your tokens have become infrastructure, and contracts don't get amended without someone noticing. The governance failure that follows tends to be slow: something is slightly off everywhere, nobody can point to when it changed, and unwinding it costs more than the review would have.
GitHub Primer published their own MCP server specifically so agents can query their design system authoritatively, rather than hallucinating component names or token values. The boundary is built into what the server exposes: read access to components and tokens, nothing that touches the repository directly. Policy documents don't enforce themselves, and agents don't read governance wikis. The boundary has to be in the wiring.
AGENTS.md is where that wiring lives. Where a README explains a project to humans, AGENTS.md explains it to agents. It's a cross-vendor standard now, governed by the Linux Foundation alongside MCP, and used in tens of thousands of repositories. For a design system, it holds the always-on rules for foundations, the pointer to your MCP server, and the trust tier for what agents can and cannot do. The trust tier lives there, but so does something harder to write: the reasoning behind each boundary, because the edges are where things fall apart.
A documentation typo auto-merges; a component description change goes to a draft PR. That seems obvious until a typo correction changes a code example, which is a semantic change, not a spelling error. A token alias update might look like a description change and behave like an API change. If you haven't written down the reasoning, the agent will inherit your silence as permission.
MCP doesn't solve the trust problem; it surfaces it. Connecting your design system via MCP gives agents authoritative context, but it doesn't tell them what they're allowed to do with it. That's still yours to specify.
That's where most teams will get into trouble. Not because they built the loop wrong, but because they didn't think carefully enough about where the loop should stop.
If your team is spending a third of its time on maintenance — fixing regressions, correcting token misuse, updating stale documentation — a self-healing loop handles the deterministic end of that. It monitors for inconsistencies, scores severity, generates a fix, verifies, learns. An agent doing that work isn't replacing design system judgment, it's making room for it.
But the top tier still needs a human. Always. That's a deliberate choice about which decisions belong to people, and it doesn't go away with a better model.
Most teams aren't making that choice explicitly yet. Tooling is arriving faster than the governance thinking around it, and when nobody has drawn the line, the default is that the agent decides. That's fine until it isn't, and by the time you notice, it's usually compounded across enough of your system that unwinding it costs more than the review would have.
The tier is a starting point. The real task is sitting with the people who own your system and working out where each action lands. Not in the abstract, but for your components, your tokens, your consuming teams.
That conversation is overdue.
Thanks for reading! Subscribe for free to receive new posts directly in your inbox.
I’d love to stay connected – join the conversation on X and Bluesky, or connect with me on LinkedIn to talk design systems, digital products, and everything in between. If you found this useful, sharing it with your team or network would mean a lot.
Member discussion