AI Governance Is Changing: Organizations Must Govern What AI Can Do, Not Just How Employees Use It

AI governance began with sensible questions about employee use. Those questions still matter—but systems that can access resources, invoke tools, and take action introduce a second governance problem: AI authority.

Traditional AI governance asks what people are permitted to do with AI. Agentic AI governance must also address what AI is permitted to do within organizational systems.

Organizations began their generative-AI governance efforts with an understandable focus: employee behavior. Which tools may employees use? What information may they enter? How should they verify AI-generated content? When must they disclose AI assistance? Who approves a new use case?

Those questions remain essential. But they no longer describe the whole governance challenge.

AI systems are increasingly able to interact with organizational information, applications, identities, tools, development environments, APIs, cloud resources, and infrastructure. Some can perform actions with limited human involvement. Others operate as part of semi-autonomous workflows in which people set objectives, approve selected steps, or review results after actions have occurred.

From AI use to AI authority

A generative-AI assistant may produce a response to a prompt. An AI agent or AI-enabled workflow may go further. Depending on its design and permissions, it may retrieve information, update a record, create content, send a message, invoke an API, initiate a workflow, modify code, or support a deployment process.

The issue is not that every AI action is inherently dangerous. The issue is that every permitted action carries an authority decision.

• What is the AI system intended to do?
• Which information and systems can it access?
• Which identity or credential does it use?
• Which actions may it perform independently?
• Which actions require human authorization?
• Who monitors activity, owns escalation, and can disable it?
• Who remains accountable for the outcome?

A connected governance chain

A practical way to examine the issue is through the relationship among people, AI systems, information, applications, identities, and infrastructure.

HumanAIDataApplicationIdentityInfrastructure

A person may instruct an AI system. The system may retrieve data through an application. The application may rely on a service account, delegated permission, API token, or other identity. That identity may provide access to cloud services, repositories, or infrastructure.

At each layer, leadership should be able to identify ownership, authorized access, decision authority, controls, logging, escalation, human oversight, risk, and documentation. This is not simply a technical architecture exercise. It is an accountability exercise.

Identity and permissions define practical authority

An agent’s name or stated purpose does not determine what it can do. Its practical authority is shaped by the identities, service accounts, delegated permissions, API scopes, connectors, and credentials available to it.

Organizations should know whether each material agent has a distinct identity, who owns that identity, which permissions it holds, who approved them, when they are reviewed, and how they are revoked. Least-privilege principles, separation of duties, and human authorization boundaries should reflect the agent’s purpose and potential impact.

Permissions should not become permanent merely because they were convenient during a pilot.

Information access deserves the same attention

AI systems can only work with the information made available to them, but organizations often have complex and inherited access structures.

In Microsoft 365 environments, SharePoint and Teams permissions, site ownership, information organization, and existing access paths become part of the Microsoft Copilot governance discussion. Other AI systems may connect to databases, repositories, external data sources, or line-of-business applications.

Before expanding access, determine what information the AI needs, whether sensitive information is included, whether current permissions are appropriate, whether information should remain separated, who approves new connections, and how changes will be documented and reviewed.

Agent actions need explicit boundaries

Information access is only one side of the issue. Organizations must also govern what an AI system may do with that access. Depending on the use case, an agent may be able to read, write, modify, delete, execute, publish, communicate, approve, deploy, query, download, upload, or invoke other tools.

Classify actions into three groups: AI may act within defined limits; a person must review or approve; or AI is not permitted to act.

The decision may depend on context. Updating a draft in a test environment is different from publishing public content. Querying a bounded dataset is different from downloading an entire repository. Preparing a proposed change is different from deploying it.

Human approval should be attached to decisions where judgment, authority, or potential impact requires it—not added as an undefined instruction that no one owns.

Credentials and secrets are governance concerns

AI-enabled applications and agents may rely on API keys, tokens, service credentials, environment variables, cloud credentials, or repository credentials. Leadership should know who owns each credential, where it may be stored, which agent may use it, what access it provides, who rotates or revokes it, and what happens when the agent, use case, or owner changes.

A governance assessment reviews whether these responsibilities are defined and documented. That is different from credential penetration testing or technical exploitation, which requires a different scope and specialized capability.

Human oversight must be operational

“Human in the loop” is useful only when the human role is defined. Identify who provides executive sponsorship, owns the business use case and technical implementation, participates from security and risk functions, approves exceptions, and can order an agent to be disabled.

If several teams assume another team is monitoring the system, accountability becomes unclear. If no one has explicit shutdown authority, escalation may be delayed. If approval is required but the approver and decision criteria are undefined, the control may exist only on paper.

Monitoring should support accountability

Organizations should be able to determine which agent performed an action, what occurred, when it occurred, which identity or credential was used, which system or information was affected, whether approval was required and obtained, who reviews unexpected activity, who owns escalation, and who can disable the agent.

Logging alone is not accountability. Logs need an owner, a review purpose, an escalation process, and a connection to operating decisions. The monitoring level should reflect the agent’s authority and the importance of the systems it can affect.

The AI supply chain extends the governance perimeter

Enterprise AI rarely consists of a single tool. A capability may depend on third-party models, datasets, model repositories, libraries, packages, plugins, connectors, APIs, external services, AI-generated code, and AI-generated dependencies.

Leadership should know which components are used, who approved them, which systems and information they can reach, how changes are reviewed, who monitors supplier or component changes, and how AI-generated code and dependencies enter development workflows.

Specialized model assurance, malware analysis, or security engineering should be assigned to appropriately qualified specialists when required. The governance responsibility to recognize and assign that work still belongs to the organization.

Practical questions for leadership

1. Do we maintain an inventory of approved and unapproved AI tools and agents?
2. Does every material use case have business and technical owners?
3. Which identities, service accounts, permissions, and credentials does each agent use?
4. What information, applications, APIs, repositories, and environments can each system reach?
5. Which actions may agents perform independently?
6. Which actions require human review or approval?
7. Can we determine which agent performed a specific action?
8. Who reviews unexpected activity, owns escalation, and can disable the agent?
9. How are third-party models, datasets, plugins, connectors, packages, and AI-generated dependencies approved?
10. What governance decisions are most urgent during the next 90 days?

Incomplete answers do not necessarily mean AI adoption must stop. They show where governance work should begin.

A governance-first path forward

Organizations do not need to solve every AI governance question at once. They need a disciplined way to identify what exists, determine where authority and risk are concentrated, assign decisions, and build a practical roadmap.

AssessEstablish the current-state baseline.PrioritizeRank risk, dependencies, decisions, and owners.ImplementPut separately approved changes in place.SustainKeep inventories, policies, and oversight current.

Governance readiness is not technical assurance

This advisory work does not constitute penetration testing, red-team testing, vulnerability scanning, malware analysis, AI model assurance, formal AI safety certification, managed security monitoring, incident response, legal advice, regulatory certification, or a guarantee of AI security or compliance.

How PPS can help

Patriot Professional Solutions LLC helps organizations establish governance before scaling AI. The AI, Copilot & Agentic Governance Readiness assessment examines ownership, information access, permissions, human approval, operating controls, documentation, decision rights, monitoring responsibilities, and risk-management practices—and turns the findings into an accountable 90-day roadmap.

Explore AI, Copilot & Agentic Readiness