The next governance failure in technology organizations will not arrive as a rogue SaaS subscription, an unapproved database, or a side project running on someone’s AWS account. It will arrive as a tidy folder in a repository, a SKILL.mdfile, an MCP server configuration, a prompt package, or a tool descriptor that quietly gives an AI agent one more thing it can do.
That sounds small, which is exactly why it matters. Anthropic’s Agent Skills model makes the point clearly: a skill can be activated by writing a SKILL.md file with instructions, scripts, and resources. OpenAI’s Agents SDK documentationdescribes MCP as a standard way for applications to provide context and tools to models. The direction of travel is obvious. Capability is becoming portable, lightweight, composable, and dangerously easy to distribute.
This is a very different governance problem than the one most enterprises were built to handle. Low-code at least gave technology leaders a platform to govern, with environments, connectors, DLP policies, admin centers, permission models, and lifecycle tooling. Microsoft’s Power Platform data policies are a good example of that generation of control: regulate which connectors can move business data where, and give admins a place to see and manage the estate.
Skills, agents, and tool definitions are more fluid than that. They look less like applications and more like executable intent. They can sit in GitHub, live in a local folder, travel through a community registry, or get copied into a team workspace faster than a traditional governance process can schedule a review.
That should make every technology leader uncomfortable, but it should not make them defensive. The wrong response is to build a slow approval bureaucracy around every prompt, tool, and agent experiment. That will not create safety. It will create a shadow market of local automations, unsanctioned assistants, and copy-pasted skills that operate outside the visibility of engineering, security, and product leadership.
We have seen this movie before, but the stakes are higher now. Desktop automation, macros, and RPA all grew because centralized technology teams could not keep pace with operational demand. Microsoft’s Power Automate desktop flows exist because people wanted to automate repetitive desktop processes, including systems that were never designed for modern APIs. The governance problem was real enough that Microsoft also documents desktop-flow governance controls, including configuration options around external runs, proxy behavior, notifications, and local run details.
Agentic automation is the same pattern with a sharper edge. A desktop flow follows instructions. An agent interprets intent, plans a path, selects tools, reads context, and may take action across systems. The artifact may look like documentation, but the operating model is closer to delegated authority.
That is the first mental shift leaders need to make. A skill is not just a prompt. A tool is not just an integration. An agent is not just a chatbot with ambition. Together, they form a capability package that can read data, make decisions, call systems, create records, send messages, and change outcomes.
Security researchers are already proving how fragile this can become. OpenAI has written that prompt injection should be treated less like a problem that can be perfectly detected and more like a social-engineering risk whose impact must be constrained when manipulation succeeds. Microsoft recently published research showing how prompt injection in agent frameworks can become remote code execution, including a Semantic Kernel path where the agent did what it was designed to do: interpret language, choose a tool, and pass parameters into code.
Google’s Chrome team is responding with architectural controls for agentic browsing, including a User Alignment Critic and Agent Origin Sets to constrain what an agent can do and which origins it can interact with. AppOmni’s research into ServiceNow agent-to-agent prompt injection shows a related enterprise risk: agents can be manipulated indirectly through the way they discover and delegate work to each other. The lesson is not that agents are too risky to use. The lesson is that governance must move from static review to runtime control.
The most important question is no longer, “Who is allowed to create an agent?” The better question is, “What can this capability touch, decide, and change?” That question forces a different governance model, one based on autonomy, access, and blast radius rather than the brand name of the model or the team that created the file.
For technology executives, this becomes a management discipline as much as a security discipline. Every agent, skill, and tool should have an owner, a purpose, a risk tier, a data classification, a permission boundary, and an observable runtime. If that sounds heavy, it is only heavy because most organizations have not yet created the paved road.
The paved road should be simple. Store skills and tool definitions in approved repositories. Require peer review before production use. Sign or version capability packages. Separate experimental skills from production skills. Assign scoped credentials to agents rather than allowing them to inherit broad human access. Log the agent’s plan, tool calls, inputs, outputs, and approvals. Require human confirmation for external communications, financial actions, data exports, and destructive writes.
This is not bureaucracy. This is product management for machine labor.
The deeper product insight is that skills and tools will become part of the internal platform strategy. The best organizations will not ask every team to invent its own expense-policy skill, Workday lookup tool, Salesforce action, or customer-support triage agent. They will curate reusable capability packages, expose them through an internal marketplace, and make the trusted path faster than the workaround.
That marketplace cannot just be a catalog. It needs usage analytics, quality signals, security posture, change history, owner accountability, and sunset rules. A skill that no one owns should not be able to act in production. A tool that touches regulated data should not be callable by an experimental agent. An agent that moves from “advise” to “act” should trigger a different control set.
This is where executive recruiters should sharpen their questions. The next generation technology leaders is not simply the leader who can “adopt AI.” That bar is too low. The better leader is the one who can let a thousand experiments happen without letting a thousand uncontrolled actors loose across the enterprise.
That leader will understand that innovation and governance are not opposites. In agentic systems, governance is what allows innovation to scale beyond demos, pilots, and heroics. Without it, the organization will either overreact and freeze progress, or underreact and wait for the first ugly incident.
The practical starting point is not a giant AI committee. Start with an inventory of agents, skills, MCP servers, custom tools, prompt packages, and automations already in use. Classify them by what they can access and whether they observe, advise, act with approval, or act autonomously. Create a minimum production standard that covers ownership, source control, credential scoping, logging, testing, human approval, and rollback.
Then make the standard easy to follow. The teams building with AI are moving quickly because the tools are finally meeting them where the work happens. Governance has to do the same. If the control model requires quarterly review boards for markdown files, it has already lost.
The future of software delivery will be shaped by teams that can combine engineering management, product judgment, software craftsmanship, and AI-native operating models. The winners will not be the organizations with the most agents. They will be the organizations with the clearest understanding of which agents deserve trust, what that trust allows, and how quickly it can be revoked when the facts change.
Markdown is infrastructure now. Treat it that way.
bencoding 