PCC Learning Center · AI Governance
Apply Proven Security Principles to AI Tools and Agents
Verify who and what is acting, limit data and tool access to the approved purpose, and prepare for mistakes or compromise before AI receives broader authority.
The Central Idea
Do not give an employee, application or AI agent broad access merely because the initial use appears helpful. Verify the actor and context, limit authority to the task and prepare for incorrect or malicious behavior.
Verify Explicitly
Confirm the user, agent, application, owner and context. Connect every important action to the identity and authority that produced it.
Use Least Privilege
Give AI only the data, tools, actions and time required for the approved task. Start read-only and expand deliberately.
Assume Breach
Limit the blast radius, monitor behavior, preserve evidence and test how access will be stopped and data recovered.
The Three Principles Applied to AI
| Principle | Governance question | Practical controls |
|---|---|---|
| Verify explicitly | Who is the user, agent, application and owner? Is this request expected and authorized? | Managed identities, approved accounts, authentication, risk signals, named owners and user-to-agent attribution. |
| Use least privilege | What is the minimum data, system access and action capability required? | Narrow scopes, read-only defaults, tool allowlists, limited connectors, time-bound access, approval and separated environments. |
| Assume breach | What limits damage if a user, agent, instruction, credential or vendor is compromised? | Segmentation, logging, anomaly detection, action controls, tested shutdown, token revocation, backups and incident response. |
Know Every Actor in the Chain
An AI interaction can involve more identities than the person typing the prompt. Verification must preserve the chain of responsibility.
Use Managed Identities
Use approved business accounts and distinct agent or application identities instead of personal accounts or shared credentials.
Preserve Attribution
Records should distinguish the employee who initiated the work from the agent that selected or executed the tool.
Verify Context
Consider the requested resource, data sensitivity, device, location, risk signals, action and normal behavior—not identity alone.
Name Accountable Owners
Every production AI agent needs a business owner for purpose and risk and a technical owner for access, configuration, monitoring and removal.
Limit Data, Tools and Actions
Least privilege for AI covers several layers—not just one permission setting.
Data
Restrict files, sites, mailboxes, records and data classifications. Fix broad employee permissions before AI searches the same environment.
Tools
Allow only the connectors and tools required for the approved purpose. Do not add access because it might be useful later.
Actions
Separate read, draft, recommend, create, change, send and delete. Require human approval before consequential actions.
Time
Avoid permanent elevated access for occasional tasks. Remove pilot permissions when testing ends.
Environment
Keep experiments separate from production data. Use test records, restricted groups and controlled environments first.
Microsoft 365 Permissions
Copilot operates through existing user permissions. Accurate SharePoint, Teams and OneDrive access remains a prerequisite.
OAuth and Connected Apps
Review delegated and application permissions, tenant-wide consent and whether each scope is necessary for the approved use. Revoke permissions when the application or business need ends.
Service and Agent Identities
Use distinct managed identities where practical. Avoid shared credentials and preserve the relationship between the user, agent, application and action.
Access Reviews and Logs
Assign an owner, review permissions periodically and after material changes, and retain enough sign-in and activity evidence to investigate unexpected behavior.
Design for Failure and Misuse
Assume breach does not mean assuming every AI tool is malicious. It means accepting that credentials can be stolen, instructions manipulated, models wrong and controls imperfect.
Reduce the Blast Radius
Segment access by business purpose and sensitivity. One agent identity should not reach every department, data source and action.
Treat External Content as Untrusted
Documents, email and webpages may contain instructions intended to manipulate an agent. Content alone must not expand permissions or authorize sensitive actions.
Monitor Behavior
Watch for unexpected systems, unusual tools, volume spikes, bulk actions, failed permissions and changes in owner, model or connector.
Stop and Recover
Document and test how to disable the agent, block integrations, revoke tokens, preserve evidence, restore data and notify responsible people.
An Untested Kill Switch Is Only a Plan
Test rejection, shutdown, revocation and recovery paths before an agent receives broad data access or action capability.
Seven Foundations for Zero Trust AI Adoption
Inventory Tools and Agents
Record owners, accounts, data, integrations, action capabilities and review status in the AI Tool Inventory.
Assign Two Owners
Name a business owner for purpose and risk and a technical owner for identity, access and operation.
Clean Up Permissions
Review overshared files, broad groups, stale guests, old service accounts, OAuth grants and excessive tenant-wide application permissions. Use the third-party app review guide.
Define Data Boundaries
Document which data classifications each approved tool, account and feature may use.
Control Tools and Actions
Allowlist needed tools, restrict action scopes and enforce approval at meaningful control points.
Monitor and Respond
Connect AI activity and incidents to the existing response process instead of creating an isolated plan.
Review the Lifecycle
Reassess when the use, model, vendor terms, connector, permissions, owner or business process changes.
A Small-Business Starting Plan
Zero Trust is a direction and operating model—not an all-or-nothing certification.
- Find the use. Identify tools, accounts, owners, data and connected systems without making discovery punitive.
- Choose one important use case. Select meaningful business value or risk instead of trying to solve every scenario.
- Map the access path. Document the user, agent, application, OAuth scopes, data, connectors, actions and approvers.
- Remove unnecessary authority. Start read-only, restrict tools and separate testing from production.
- Test failure. Attempt out-of-scope actions and test rejection, shutdown, revocation and recovery.
- Expand deliberately. Review evidence and exceptions before adding users, data or autonomy.
Questions for Business Leaders
- Which AI tools, agents and OAuth applications are already in use?
- Does each have a business and technical owner?
- Can activity be connected to a specific user, agent and application?
- What is the most sensitive data each tool can access?
- Are employee or application permissions broader than necessary?
- Has tenant-wide consent been justified and recorded?
- Which tools and actions can each agent use?
- Where is human approval technically enforced?
- What unusual activity would create an alert?
- How quickly can access and refresh tokens be revoked?
- Has shutdown and recovery been tested?
- What change would trigger a new review?
Do Not Expand Access Without Answers
If the business cannot answer these questions, adding more users, data or AI autonomy should not be the next step.
Strengthen the Security Foundations Behind AI
Responsible AI adoption depends on identity, permissions, data protection, monitoring and clear ownership. These are extensions of the same IT and cybersecurity controls your business already relies on.
PCC helps Bay Area businesses strengthen those foundations across Microsoft 365, cybersecurity and managed IT.
Choosing an AI platform is also a governance decision.
Our ChatGPT vs. Claude Business Decision Guide helps businesses compare platform capabilities alongside identity, data-handling and oversight requirements.