Over the past year, I have had conversations with security leaders across a variety of disciplines, and the energy around AI is undeniable. Organizations are moving fast, and security teams are rising to meet the moment. Time and again, the question comes back to the same thing: “We’re adopting AI fast, how do we make sure our security keeps pace?”

It’s the right question, and it’s the one we’ve been working to answer by updating the tools and guidance you already rely on. We’re announcing Microsoft’s approach to Zero Trust for AI (ZT4AI). Zero Trust for AI extends proven Zero Trust principles to the full AI lifecycle—from data ingestion and model training to deployment and agent behavior. Today, we’re releasing a new set of tools and guidance to help you move forward with confidence:

• A new AI pillar in the Zero Trust Workshop.
• Updated Data and Networking pillars in the Zero Trust Assessment tool.
• A new Zero Trust reference architecture for AI.
• Practical patterns and practices for securing AI at scale.

Here’s what’s new and how to use it.

Why Zero Trust principles must extend to AI

AI systems don’t fit neatly into traditional security models. They introduce new trust boundaries—between users and agents, models and data, and humans and automated decision-making. As organizations adopt autonomous and semi-autonomous AI agents, a new class of risk emerges: agents that are overprivileged, manipulated, or misaligned can act like “double agents,” working against the very outcomes they were built to support.

By applying three foundational principles of Zero Trust to AI:

• Verify explicitly—Continuously evaluate the identity and behavior of AI agents, workloads, and users.
• Apply least privilege—Restrict access to models, prompts, plugins, and data sources to only what’s needed.
• Assume breach—Design AI systems to be resilient to prompt injection, data poisoning, and lateral movement.

These aren’t new principles. What’s new is how we apply them systematically to AI environments.

A unified journey: Strategy → assessment → implementation

The most common challenge we hear from security leaders and practitioners is a lack of a clear, structured path from knowing what to do to doing it. That’s what Microsoft’s approach to Zero Trust for AI is designed to solve—to help you get to next steps and actions, quickly.

Zero Trust Workshop—now with an AI pillar

Building on last year’s announcement, the Zero Trust Workshop has been updated with a dedicated AI pillar, now covering 700 security controls across 116 logical groups and 33 functional swim lanes. It is scenario-based and prescriptive, designed to move teams from assessment to execution with clarity and speed.

The workshop helps organizations:

• Align security, IT, and business stakeholders on shared outcomes.
• Apply Zero Trust principles across all pillars, including AI.
• Explore real-world AI scenarios and the specific risks they introduce.
• Identify cross-product integrations that break down silos and drive measurable progress.

The new AI pillar specifically evaluates how organizations secure AI access and agent identities, protect sensitive data used by and generated through AI, monitor AI usage and behavior across the enterprise, and govern AI responsibly in alignment with risk and compliance objectives.

Zero Trust Assessment—expanded to Data and Networking

As AI agents become more capable, the stakes around data and network security have never been higher. Agents that are insufficiently governed can expose sensitive data, act on malicious prompts, or leak information in ways that are difficult to detect and costly to remediate. Data classification, labeling, governance, and loss prevention are essential controls. So are network-layer defenses that inspect agent behavior, block prompt injections, and prevent unauthorized data exposure.

Yet, manually evaluating security configurations across identity, endpoints, data, and network controls is time consuming and error prone. That is why we built the Zero Trust Assessment to automate it. The Zero Trust Assessment evaluates hundreds of controls aligned to Zero Trust principles, informed by learnings from Microsoft’s Secure Future Initiative (SFI). Today, we are adding Data and Network as new pillars alongside the existing Identity and Devices coverage.

Zero Trust Assessment tests are derived from trusted industry sources including:

• Industry standards such as the National Institute of Standards and Technology (NIST), the Cybersecurity and Infrastructure Security Agency (CISA), and the Center for Internet Security (CIS).
• Microsoft’s own learnings from SFI.
• Real-world customer insights from thousands of security implementations.

And we are not stopping here. A Zero Trust Assessment for AI pillar is currently in development and will be available in summer 2026, extending automated evaluation to AI-specific scenarios and controls.

Overall, the redesigned experience delivers:

• Clearer insights—Simplified views that help teams quickly identify strengths, gaps, and next steps.
• Deep(er) alignment with the Workshop—Assessment insights directly inform workshop discussions, exercises, and deployment paths.
• Actionable, prioritized recommendations—Concrete implementation steps mapped to maturity levels, so you can sequence improvements over time.

Zero Trust for AI reference architecture

Our new Zero Trust for AI reference architecture (extends our existing Zero Trust reference architecture) shows how policy-driven access controls, continuous verification, monitoring, and governance work together to secure AI systems, while increasing resilience when incidents occur.

The architecture gives security, IT, and engineering teams a shared mental model by clarifying where controls apply, how trust boundaries shift with AI, and why defense-in-depth remains essential for agentic workloads.

Practical patterns and practices for AI security

Knowing what to do is one thing. Knowing how to operationalize it at scale is another. Our patterns and practices provide repeatable, proven approaches to the most complex AI security challenges, much like software design patterns offer reusable solutions to common engineering problems.

Pattern	What it helps you do
Threat modeling for AI	Why traditional threat modeling breaks down for AI—and how to redesign it for real-world risk at AI scale.
AI observability	End-to-end logging, traceability, and monitoring to enable oversight, incident response, and trust at scale.

See it live at RSAC 2026

If you’re attending RSAC™ 2026 Conference, join us for three sessions focused on Zero Trust for AI—from expanding attack surfaces to hands-on, actionable guidance.

When	Session	Title
Wednesday, March 25, 2026, 11:00 AM PT-11:20 AM PT	Zero Trust Theatre Session, by Tarek Dawoud (Principal Group Product Manager, Microsoft Security) and Hammad Rajjoub (Director, Microsoft Secure Future Initiative and Zero Trust)	Zero Trust for AI: Securing the Expanding Attack Surface
Wednesday, March 25, 2026, 12:00 PM PT-1:00 PM PT	Ancillary Executive Session, by Travis Gross (Principal Group Product Manager, Microsoft Security), Eric Sachs (Corporate Vice President, Microsoft Security), and Marco Pietro (Executive Vice President, Global Head of Cybersecurity, Capgemini), moderated by Mia Reyes (Director of Security, Microsoft).	Building Trust for a Secure Future: From Zero Trust to AI Confidence
Thursday, Marxh 26, 2026, 11:00 AM PT-12:00 PM PT	RSAC Post-Day Workshop, by Travis Gross, Tarek Dawoud, Hammad Rajjoub	Zero Trust, SFI, and ZT4AI: Practical, actionable guidance for CISOs

Get started with Zero Trust for AI

Zero Trust for AI brings proven security principles to the realities of modern AI. Whether you’re governing agents, protecting models and data, or scaling AI without introducing new risk, the tools, architecture, and guidance are ready for you today.

Get started:

• Explore Microsoft’s unique approach to Zero Trust (including Zero Trust for AI).
• Implement your Zero Trust architecture for AI your way—self-service, through a trusted partner, or directly with Microsoft.
• Execute the Zero Trust Workshop to move from strategy to execution with scenario-based, prescriptive guidance.
• Assess your Zero Trust posture and explore the new Data and Network pillars with the Zero Trust Assessment tool.

To continue the conversation, join the Microsoft Security Community, where security practitioners and Microsoft experts share insights, guidance, and real world experiences across Zero Trust and AI security.

Learn more about Microsoft Security solutions on our website and bookmark the Microsoft Security blog for expert insights on security matters. Follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest cybersecurity news and updates.

The post New tools and guidance: Announcing Zero Trust for AI appeared first on Microsoft Security Blog.

Let me paint a picture for you.

A polished pull request lands in your inbox. It looks amazing at first glance, but then you start digging in, and a few things seem off. Forty-five minutes later, you’ve crafted a thoughtful, encouraging response with a few clarifying questions. Who knows: Maybe this person might be a great new person to mentor, so it’s worth your time if they put in theirs.

And then…nothing. Or the follow-up makes it clear the contributor doesn’t have the context needed to explain the change, often because AI made it easy to submit something plausible before they were ready to maintain it. Or you realize you’ve just spent your afternoon debugging someone’s LLM chat session.

This is becoming more common. Not because contributors are acting in bad faith, but because it’s never been easier to generate something that looks plausible. The cost to create has dropped. The cost to review hasn’t.

Open source is experiencing its own “Eternal September”: a constant influx of contributions that strains the social systems we rely on to build trust and mentor newcomers.

The signals have changed

Projects across the ecosystem are seeing this same occurrence. tldraw closed their pull requests. Fastify shut down their HackerOne program after inbound reports became unmanageable at scale.

The overall volume keeps climbing. The Octoverse 2025 report notes that developers merged nearly 45 million pull requests per month in 2025 (up 23% year over year). More pull requests, same maintainer hours.

The old signals, like clean code, fast turnaround, and handling complexity, used to mean someone had invested time into understanding the codebase. Now AI can help users generate all of that in seconds, so these signals aren’t as telling.

To reduce noise and bring more trust back into open source contributions, platforms, including GitHub, are building longer-term solutions. In fact, our product team just published an RFC for community feedback. If you have thoughts on what we can do, we’d love to hear from you.

But platform changes take time. And even when they arrive, you’ll still need strategies for figuring out how mentorship looks today when signals aren’t as easy to read. Here’s what’s working.

Why this is urgent

Mentorship is how open source communities scale.

If I asked a room of open source contributors how they got started, they’d all say it began with a good mentor.

When you mentor someone well, you’re not just adding one contributor. You’re multiplying yourself. They learn to onboard others who do the same. That’s the multiplier effect.

Year	Broadcast (1,000/year)	Mentorship (2 every 6 months, they do the same)
1	1,000	9
3	3,000	729
5	5,000	59,049

But maintainers are burning out trying to mentor everyone who sends a pull request. If we lose mentoring newcomers, we lose the multiplier entirely.

We can’t abandon mentorship, especially as many long-time maintainers step back from active contribution. (I wrote more about this generational challenge in Who will maintain the future?) So, we need to be strategic about who we invest in.

The 3 Cs: A framework for strategic mentorship at scale

So how do you decide where to invest your mentorship energy when contribution signals are harder to read? Looking at what’s working across projects, I see three filters maintainers are using. I call them the 3 Cs: Comprehension, Context, and Continuity.

1. Comprehension

Do they understand the problem well enough to propose this change?

Some projects now test comprehension before code is submitted. Codex and Gemini CLI, for example, both recently added guidelines: contributors must open an issue and get approval before submitting a pull request. The comprehension check happens in that conversation.

I’m also seeing in-person code sprints and hackathons thriving in this area, where maintainers can have real-time conversations with potential contributors to check both interest and comprehension.

I’m not expecting contributors to understand the whole project. That’s unrealistic. But you want to make sure they’re not committing code above their own comprehension level. As they grow, they can always take on more.

2. Context

Do they give me what I need to review this well?

Comprehension is about their understanding. Context is about your ability to do your job as a reviewer.

Did they link to the issue? Explain trade-offs? Disclose AI use?

The last one is becoming more common. ROOST has a simple three-principle policy. The Processing Foundation added a checkbox. Fedora landed a lightweight disclosure policy after months of discussion.

Disclosing AI is about giving reviewers context. When I know a pull request was AI-assisted, I can calibrate my review. This might mean asking more clarifying questions or focusing on whether the contributor understands the trade-offs, not just whether the code runs.

There’s also AGENTS.md, which provides instructions for AI coding agents, like robots.txt for Copilot. Projects like scikit-learn, Goose, and Processing use AGENTS.md to tell agents instructions, like follow our guidelines, check if an issue is assigned, or respect our norms. This can help to place the burden of gathering the context needed for a review to the contributor (or their tools).

3. Continuity

Do they keep coming back?

This is the mentorship filter.

Drive-by contributions can be helpful but limit your mentorship investment to people who come back and engage thoughtfully.

Your mentorship can scale up over time:

• Great first conversation in a pull request → make your review a teachable moment
• They keep coming back → offer to pair on something, then start suggesting harder tasks
• If they still keep coming back → invite them to an event, or consider commit access

The takeaway

Comprehension and Context get you reviewed. Continuity gets you mentored.

As a maintainer, this means: don’t invest deep mentorship energy until you see all three.

What this looks like:

PR Lands → Follows Guidelines?  
                NO  → Close. Guilt-free. 
                YES → Review → They Come Back?
                                    YES → Consider Mentorship 

Let’s compare this to our first example above. This time, a polished pull requests lands without following the guidelines. Close it. Guilt-free. Protect your time for contributions that matter.

If someone comes back and is engaged in issues; if they submit a second pull request and respond thoughtfully to feedback, now you pay attention. That’s when you invest.

This is how you protect the multiplier effect. You’re not abandoning newcomers. You’re being strategic.

There’s another benefit too: clear criteria reduces bias. When you rely on vibes, you tend to mentor people who look like you or share your cultural context. The 3 Cs give you a rubric instead of gut feelings, and that makes your mentorship more equitable.

Getting started

Pick a C to implement:

C	Implementation
Comprehension	Require issue before pull request Host an in-person code sprint for live discussions
Context	Add AI disclosure or AGENTS.md
Continuity	Watch who comes back

Start with one but look for all three when deciding who to mentor.

This isn’t about restricting AI-assisted contributions. It’s about building guardrails that protect human mentorship and keep communities healthy.

AI tools are here to stay. The question is whether we adapt our practices to maintain what makes open source work: human relationships, knowledge transfer, and the multiplier effect.

The 3 Cs give us a framework for exactly that.

Resources

• GitHub RFC for platform-level solutions
• OpenAI Codex contribution policy
• Google Gemini CLI contribution policy
• ROOST AI policy
• Fedora AI contribution policy
• Processing AGENTS.md
• scikit-learn pull request template
• Goose HOWTOAI.md

Adapted from my FOSDEM 2026 talk. Thanks to Anne Bertucio, Ashley Wolf, Daniel Stenberg, Tim Head, Bruno Borges, Emma Irwin, Helen Hou-Sandí, Hugo van Kemenade, Jamie Tanna, John McBride, Juan Luis Cano Rodríguez, Justin Wheeler, Matteo Collina, Camilla Moraes, Raphaël de Courville, Rizel Scarlett, and everyone who shared examples online.

The post Rethinking open source mentorship in the AI era appeared first on The GitHub Blog.

If you’ve used AI coding tools before, you know the pattern. You write a prompt, the model misunderstands, you refine it, and you coax better output. Progress depends more on steering the model than on building the software.

As projects grow, the challenge stops being “how do I prompt?” and starts becoming “how do I coordinate design, implementation, testing, and review without losing context along the way.”

Multi-agent systems are a great way to move past this plateau, but usually require a massive amount of setup. People spend hours building orchestration layers, wiring up frameworks, and configuring vector databases before they can delegate a single task.

Squad, an open source project built on GitHub Copilot, initializes a preconfigured AI team directly inside your repository. It is a bet that multi-agent development can be accessible, legible, and useful without requiring heavy orchestration infrastructure or deep prompt engineering expertise.

Two commands—npm install -g @bradygaster/squad-cli once globally, squad init once per repo—and Squad drops a specialized AI team: a lead, frontend developer, backend developer, and tester directly against your repository.

Instead of a single chatbot switching roles, Squad demonstrates repository native multi-agent orchestration without heavy centralized infrastructure.

How Squad coordinates work across agents

You describe the work you need done in natural language. From there, a coordinator agent inside Squad figures out the routing, loads repository context, and spawns specialists with task-specific instructions.

For example, you type: “Team, I need JWT auth—refresh tokens, bcrypt, the works.” Then you watch the team spin up in parallel. The backend specialist takes the implementation. The tester starts writing the accompanying test suite. A documentation specialist opens a pull request. Within minutes, files are written and branches are created. These specialists already know your naming conventions and what you decided about database connections last Tuesday—not because you put it in the prompt, but because agents load from shared team decisions and their own project history files committed to the repository.

Instead of forcing you to manually test the output and prompt the model through multiple rounds of fixes, Squad handles iteration internally. Once the backend specialist drafts the initial implementation, the tester runs their test suite against it. If those tests fail, the tester rejects the code. Crucially, the orchestration layer prevents the original agent from revising its own work. Squad’s reviewer protocol can prevent the original author from revising rejected work, and a different agent must step in to fix it. This forces genuine independent review with a separate context window and a fresh perspective, rather than asking a single AI to review its own mistakes. In workflows where reviewer automation is enabled, you review the pull request that survives this internal loop rather than every intermediate attempt.

It’s not autopilot, and it’s not magic on session one. Agents will ask clarifying questions and sometimes make reasonable but wrong assumptions. You still review and merge every pull request. It is collaborative orchestration, not autonomous execution.

Architectural patterns behind repository-native orchestration

Whether you use Squad or build your own multi-agent workflows, there are a few architectural patterns we’ve learned from building repository-native orchestration. These patterns move the architecture away from “black box” behavior toward something inspectable and predictable at the repository level.

1. The “Drop-box” pattern for shared memory

Most AI orchestration relies on real-time chat or complex vector database lookups to keep agents in sync. We’ve found that this is often too fragile; synchronizing state across live agents is a fool’s errand.

Instead, Squad uses a “drop-box” pattern. Every architectural choice, like choosing a specific library or a naming convention, is appended as a structured block to a versioned decisions.md file in the repository. This is a bet that asynchronous knowledge sharing inside the repository scales better than real-time synchronization. By treating a markdown file as the team’s shared brain, you get persistence, legibility, and a perfect audit trail of every decision the team has made. Because this memory lives in project files rather than a live session, the team can also recover context after disconnects or restarts and continue from where it left off.

2. Context replication over context splitting

One of the biggest hurdles in AI development is the context window limit. When a single agent tries to do everything, the “working memory” gets crowded with meta-management, leading to hallucinations.

Squad solves this by ensuring the coordinator agent remains a thin router. It doesn’t do the work; it spawns specialists. Because each specialist runs as a separate inference call with its own large context window (e.g., up to 200K tokens on supported models), you aren’t splitting one context among four agents, you’re replicating repository context across them.

Running multiple specialists in parallel gives you multiple independent reasoning contexts operating simultaneously. This allows each agent to “see” the relevant parts of the repository without competing for space with the other agents’ thoughts.

3. Explicit memory in the prompt vs. implicit memory in the weights

We believe an AI team’s memory should be legible and versioned. You shouldn’t have to wonder what an agent “knows” about your project.

In Squad, an agent’s identity is built primarily on two repository files: a charter (who they are) and a history (what they’ve done), alongside shared team decisions. These are plain text. Because these live in your . squad/ folder, the AI’s memory is versioned right alongside your code. When you clone a repo, you aren’t just getting the code; you are getting an already “onoboarded” AI team because their memory lives alongside the code directly in the repository.

Lowering the barrier to multi-agent workflows

Our biggest win with Squad is that it makes it easy for anyone to get started with agentic development in a low-touch, low-ceremony way. You shouldn’t have to spend hours wrestling with infrastructure, learning complex prompt engineering, or managing convoluted CLI interactions just to get an AI team to help you write code.

The post How Squad runs coordinated AI agents inside your repository appeared first on The GitHub Blog.

I found out about accessibility in college, eight or nine years ago, and loved it so much it became my thesis. From then on, I was often the only person in the room excited enough to talk about it – I persisted, advocated, learned more, and fought to raise awareness.

Rarely did anyone listen, it wasn’t important. Until last year.

When the European Accessibility Act became law, suddenly everyone wanted to talk about accessibility. I was in meetings, resources were finally allocated, and the thing I’d been shouting about for nearly a decade was at last… important.

I should have been thrilled. Instead, I felt nothing.

Anyone, anywhere, should be able to use the web

Tim Berners-Lee said:

The power of the Web is in its universality.

I believed it in college, and I still believe it today: the web should be accessible to everyone. That’s the foundational principle behind the platform we build every day.

But for most of my career, that principle wasn’t even on the radar. I watched us build walls in a medium meant to have none and I kept speaking up anyway, because someone had to.

I‘d won the battle and lost the war

Then 2025 arrived – the European Accessibility Act. Accessibility wasn’t optional anymore, it was a legal requirement. And suddenly, people listened.

Finally, I was having real conversations about accessibility – the thing I’d wanted for eight years. But it wasn’t because most people truly cared, they were asking only because they had to.

For the most part, few conversations focused on the 15% of users who experience the web differently. Most discussions were about checkboxes, compliance audits, and legal exposure, rather than creating experiences that work for everyone.

I’d won the battle and lost the war: accessibility was happening, but the why (the empathy, the principle, the universality of the web) was missing.

Let’s fix something that isn’t broken

You know what’s funny? Everything was fine for a while.

Native HTML elements come with accessibility built in. A <select> is usable by default, and a <button> handles keyboard interaction automatically – HTML was designed with accessibility in mind. The challenge comes when we want to style them: for example, dropdowns are notoriously hard to customize, so they often end up looking like the browser’s default, which can feel “ugly” compared to the rest of our design.

So we built custom ones and this where we start to lose accessibility. We didn’t mean to, we just wanted things to look better. But in chasing the shiny new, we broke what worked.

I guess it got to the point where enough people with disabilities were heard, and finally someone started to care. And now here we are, trying to fix what we broke with our shiny new toys. I’m glad we’re here. If we can, we should take everyone into consideration. It’s also good for business or something—I don’t know, I’m just a developer

But here’s what I do know: ship fast, yes, but don’t skimp on quality. Every commit carries your name, and that matters.

Accessibility automated – no brain cells required

So here I am: building accessible components, creating tools to automate accessibility, and teaching AI to check WCAG compliance. The idea: make accessibility so easy developers don’t have to think about it. Use our Bepo components – get compliance for free, ship accessible products, no explanations required.

After eight years of trying to get people to care, I’m now building systems so they don’t have to. The irony isn’t lost on me.

We’ve built Navigation with a ton of keyboard interactions developers never had to write. Broadcast with ARIA patterns they never had to learn. Color contrast decisions made at the token level. Focus management handled automatically. Claude Code plugin that catches accessibility issues in code review.

It works. Users benefit. Rarely anyone understands why. And that haunted me.

And still, I couldn’t sleep at night

I wrestled with it for months. Had I traded education for efficiency? Made accessibility just a checklist, a tool, not a principle? Where was the empathy in automation?

We’re not just building components, we’re building experiences. Real experiences for real people: those who navigate with keyboards, rely on screen readers, need high contrast, struggle with complex interactions, or depend on assistive technologies.

How do you automate caring about those people?

I thought I understood select… until I actually built one

Until recently, I didn’t really understand the difference between Select and Combobox. I thought I did, I could cite the ARIA spec, but I didn’t. I’d accepted what authorities said without questioning it. In our design system, they were just one Select component… like in many UI libraries. So I never questioned it.

There’s really no difference in what a screen reader announces – Select and Combobox have the same role. I guess Select came first and ARIA later, so the role applies to both. So having just one component… almost the same, right?

Except if you care about the structure of these elements, what it means, and why you can’t fully follow the pattern with just one component. That’s the tricky part

I didn’t really know about the Combobox, until frustration made me curious.

I dove into building a “vanilla” Select from scratch – ARIA patterns, screen reader testing, understanding user expectations, the whole thing. And I realized: modern components don’t really follow patterns. Some tools are technically correct, but they feel… wrong. Clunky. Not what users expect.

Bridging UX gaps is about making interfaces seamless, accessible, and human-first

This is the UX gap. We want custom, modern, polished, and accessible but there’s a bridge missing between the spec and good UX.

I realized: we can have almost all of it if we build with the experience in mind. Combine patterns. Use micro knowledge (like tabbing to inputs or arrowing through options) to make the Select feel as clear as native. Screen reader and keyboard should just make sense.

Average users don’t know about triggers. They just want to open the Select and pick an option. Keep it simple.

As a frontend developer, I see myself as a bridge between users and what I build. It’s my responsibility to make interfaces the best they can be, and to care about them.

You know what I had the most fun with while building my Select? Focus and keyboard interactions. It’s seamless, it works beautifully, exactly as I expect.

I see it in chunks: arrows navigate options, tab moves to buttons, links, inputs. But here’s the twist: if a Select has a custom footer with action buttons, arrows should still navigate options. The footer isn’t part of the pattern; it’s our addition. That’s where we bridge the gap. Or, as the Brits say: mind the gap.

This is the space for custom solutions, where language standards and patterns meet usability, inclusivity, and the full interaction experience.

Building that Select taught me the difference between patterns, user expectations, and implementation flexibility. It was so much fun.

I’ve always loved HTML and CSS – the right semantic element, the right ARIA role, perfect keyboard navigation. It’s craftsmanship. Most users won’t notice, they’ll just use the Select. That’s the point: good infrastructure and accessibility are invisible. You only notice when it’s missing.

We need the knowledge, the understanding, the empathy. UX gaps can’t be automated. Someone has to know what they’re building and who they’re building it for. That’s deep work. And it matters.

The accessibility reconciliation that gave me peace

Then I realized something:

I don’t need everyone to care the way I care, I need everyone to build accessible products. Those aren’t the same thing. And pretending they are was making me miserable.

Here’s the mental model that gave me peace:

Tier 1: The Foundation

• Use accessible components correctly
• Trust the automation
• Get accessibility “for free”
• Ship accessible products without deep expertise

This is how we scale accessibility: give people the right tools and let them use them.

Tier 2: The Curious

• Understand the patterns and why they work 
• Can compose components accessibly
• Catch edge cases automation misses
• Teach others

This is where cultural change happens: people see when automation isn’t enough, ask why, learn deeper patterns, and build better products for their users.

Tier 3: The Champions

• Deep expertise
• Build the infrastructure
• Advance the field
• Fight the eight-year battles

This is where I live, building the tools that make Tier 1 possible.

For eight years, I tried to push everyone to Tier 3, make everyone care as much as I did. I failed. I was exhausted. And I’ve realized I can’t make everyone care, but I can build the infrastructure, play the long game, and ship accessible products anyway. Maybe some will get curious, maybe they won’t, but by making accessibility the default, we create space for learning and a future where it’s just how things work.

Automation doesn’t give up; it accepts that people engage differently.

The door is always open: use components (Tier 1), get curious (Tier 2), contribute patterns (Tier 3). Or stay at Tier 1. That’s fine. That’s success. That’s an accessible product shipped.

You don’t need everyone to care, but everyone can benefit from what you build

If you build accessibility infrastructure, your work matters, even when it’s invisible. Build the safety net, automate what you can, and leave the door open for those who want to see how it works.

If you’re a developer: Tier 1 is enough: use the accessible components, trust the tooling, ship accessible products. Tier 2 is there if you’re curious: learn the patterns, understand your users, make better products. Tier 3 is there if you’re passionate: join us. We’ve been out here a while; it’s lonely sometimes, and we’d love the company.

After eight years in the wilderness, I’m finally building the tools – tools that make accessibility easy, scale empathy, and create experiences for everyone. That’s the infrastructure that matters. And that’s enough.

The post You don’t need to care, just make your products accessible appeared first on ShiftMag.

The risk isn’t just that we’ll get lazy and become lousy at critical thinking; the risk is that we’ll outsource our judgement and lose the ability to make qualitative, moral, and interpersonal judgments altogether.

Most enterprises claim to govern their AI use. They have policy documents, review boards, approval flows, and sandbox environments.

On paper, control exists. Then agents enter real software delivery workflows.

They generate code, refactor systems, open pull requests, query internal data, trigger automations, and coordinate across tools. They move from experiment to execution. At that point, many organizations lose visibility, control, and cost accountability.

Governance designed for static systems breaks under dynamic agents.

The illusion of control

Enterprise AI governance today remains largely abstract. Organizations define policies, approval processes, and access controls. They specify which models teams can use and where experimentation can happen.

These mechanisms work in contained environments, but they break down when agents operate at scale inside production systems.

This creates governance, with:

• No clear visibility into agent actions and decision paths.
• No enforceable link between policy and execution.
• No reliable way to attribute cost or measure effectiveness.
• A false sense of control that increases risk rather than reducing it.

The most dangerous part isn’t the lack of control. It is the belief that control already exists.

Policies describe intent, agents decide behavior

As agents gain autonomy, they make micro-decisions inside workflows that policy documents never anticipated. Governance frameworks define permissions, approval gates, and high-level constraints.

They rarely account for how an agent interprets context, chains tools, or explores edge cases while attempting to complete a task. The result is a structural gap. Organizations assume that if rules exist, behavior will follow.

In reality, agents operate more like capable teenagers. You can set clear rules. You can explain the boundaries. Yet curiosity, optimization logic, or a creative interpretation of an objective can produce actions no one explicitly planned for.

My teenage daughter loves to cook and bake. She is independent and does not require supervision. She knows the rules: wash the dishes, wipe down surfaces, and leave the kitchen as you found it. I trust her to operate within those boundaries.

One afternoon, she got curious and decided to test what would happen if she combined cola and Mentos. On their own, the ingredients were harmless. Once she combined them, they became a problem. Nothing was broken. But I had not anticipated cleaning soda off the ceiling. The rules existed. An unexpected outcome still emerged.

Agents behave in a similar way. They pursue goals, generate code, call APIs, trigger workflows, and access data in ways that may sit technically within permission boundaries but outside the spirit of the policies.

Traditional governance has no mechanism to observe or intervene in these runtime decisions. When autonomy increases, static policy loses reach.

Cost without clarity

Even when behavior does not create immediate risk, it creates opacity.

Agents consume tokens, call external models, execute workflows, and use internal tools. Costs accumulate across teams and projects. Without integrated visibility, finance teams see invoices but not what the costs are ultimately for. Engineering leaders see velocity changes but not the economic trade-offs behind them.

At the same time, few organizations can answer even basic questions while assessing results, such as:

• What did the agent actually do?
• How reliably did it perform?
• What tools did it use and with which permissions?
• Did it improve delivery speed or introduce duplicate work? 
• What value did it generate relative to its cost?

Without answers to these questions, governance becomes performative. It satisfies compliance checklists while leaving the operational reality unexamined.

Governance only works when it has sight

If organizations can’t observe AI behavior, enforce controls at runtime, and understand economic impact, they do not have operational governance.

Governance that exists only in policy documents remains theoretical. Real governance must be built into the AI system itself.

This requires a reframing. Governance isn’t a committee. It isn’t a framework layered on top of agents. It is an operating ecosystem.

Governance must be embedded by design, woven into how agents are built, orchestrated, deployed, and monitored from day one.

What governance by design looks like practically

A governance-by-design ecosystem includes runtime enforcement of organizational policies, coordinated management of models and providers, structured orchestration of agents, deep visibility into execution paths, auditability, and transparent cost attribution.

It restricts agent capabilities through tool and skill allowlists, least privilege permissions, and blast radius reduction. It isolates agents through segmentation, so if one is compromised or behaves unpredictably, the impact does not spread laterally across the company.

It also embeds continuous evaluation. Quality checks, policy validation, and hallucination detection must form part of the operating environment. If you can’t measure output quality, detect fabricated responses, and identify when agent behavior drifts from policy or intended objectives, you can’t claim meaningful governance.

Most importantly, this ecosystem would make that oversight transparent and actionable. Different stakeholders would see what matters at their level: engineering teams would monitor execution paths and quality signals; platform teams would enforce policy boundaries and manage model access; product leaders would evaluate impact and trade-offs; executives would understand risk exposure and economic return.

Governance would no longer slow adoption. Instead, it would create the conditions for confident scaling.

Why this matters now

Agents are already operating in production. They write code, manage infrastructure, triage incidents, and coordinate work across teams. This isn’t a future scenario – a shift that’s already happening – and adoption is accelerating.

If governance depends on trust rather than visibility, it’s already ineffective.

The question isn’t whether you have an AI policy. It’s whether you can monitor what your agents are doing, control how they do it, and understand what it costs.

If you can’t, then your governance is aspirational, not operational. And that gap will only widen as agent autonomy increases.

Let me know what you think in the comments.