The development owners should watch
AI tools are moving from occasional chat assistance into business workflows. They may summarize mail, search documents, draft responses, classify requests, update records, or trigger actions through connected applications. The important security question is not whether an AI system is intelligent. It is what authority the system receives and what information it can reach.
As of August 26, 2026, the details vary by product and tenant. Some capabilities are generally available, some are previews, and some depend on licensing or administrator configuration. Treat vendor announcements as product-specific documentation, not proof that every organization has the same feature or risk.
An AI tool inherits the access around it
If an assistant can search a user’s files, it may expose information that was already overshared. If it can send messages, edit records, or call an external service, an incorrect instruction may have an operational consequence.
Before approving an AI workflow, document:
- The human or service identity used.
- Applications and data sources connected.
- Read, write, send, purchase, or delete permissions.
- Whether actions require human approval.
- Data retention and provider training terms.
- Logging and review capabilities.
- How access is removed when the project ends.
Microsoft’s identity security guidance emphasizes restricting application registration, reviewing permissions, using scoped provisioning, and replacing long-lived secrets with certificates or managed identities where appropriate. Those principles apply broadly to AI-connected applications.
Start with low-consequence use cases
A small office does not have to ban AI to manage risk. Begin with use cases that have limited consequences:
- Drafting internal agendas from non-sensitive notes.
- Summarizing public information.
- Creating first drafts that a person must review.
- Classifying routine requests without automatically responding.
- Searching a deliberately limited knowledge base.
Delay workflows involving medical records, privileged legal advice, payment instructions, payroll changes, customer identity documents, or automatic external communication until access, retention, review, and incident handling are clear.
Establish an approval boundary
The more consequential the action, the stronger the human approval requirement should be. A useful pattern is:
- Read-only access for experimentation.
- Draft-only output for communications.
- Human approval before sending or changing records.
- Dual approval for payments, access changes, or sensitive disclosures.
- No autonomous deletion of business records.
“Human in the loop” is not meaningful if the person approves every request without seeing the source, destination, or exact action. The approval screen should make the consequence understandable.
Control data exposure
Create an inventory of approved AI tools and connected data sources. Establish a simple rule for employees: do not place confidential information into an AI service unless the business has approved the service and understands its terms.
Protect the underlying data as well:
- Remove broad anonymous or external sharing.
- Review group memberships and inherited permissions.
- Separate sensitive repositories from general knowledge sources.
- Apply retention and deletion rules.
- Monitor unusual downloads or bulk searches.
- Avoid using production data for testing when realistic sample data will work.
The tool may be functioning as designed while the data permissions are too broad. That is why AI governance cannot be separated from ordinary identity and information management.
Treat AI agents as managed identities
If an agent or automation can act without a person’s immediate sign-in, manage it like a business account. Assign an owner, purpose, scope, expiration or review date, and emergency disablement method.
Maintain a register containing:
- Agent name and business purpose.
- Platform and connected applications.
- Permissions and secrets.
- Data sources.
- Approval requirements.
- Logs and review frequency.
- Owner and backup owner.
Never leave an unowned automation connected to sensitive systems. Review whether it uses a long-lived secret, broad administrator permission, or personal employee account.
Prepare for prompt and instruction abuse
AI systems can receive untrusted instructions through emails, documents, websites, or records. A malicious document may attempt to influence an assistant’s behavior. Controls should therefore include source restrictions, tool limitations, output review, and logging.
Do not rely on the model to distinguish every malicious instruction. Restrict what it can do if it is wrong. Require confirmation for external side effects and keep a manual alternative for critical operations.
What is confirmed versus uncertain
Confirmed: AI-connected workflows expand the importance of identity, application permissions, data governance, and auditability. Confirmed: Microsoft recommends stronger controls for application registration, consent, secrets, and privileged access. Uncertain: the behavior and security features of any specific AI product depend on its documentation, configuration, licensing, and release stage.
A 30-day governance sprint
- Days 1–7: inventory current AI tools and informal employee use.
- Days 8–14: classify proposed use cases by data sensitivity and consequence.
- Days 15–21: restrict permissions and require human approval for external actions.
- Days 22–30: document owners, test logs, and rehearse emergency disablement.
The practical lesson is not “automate everything” or “ban everything.” It is to make authority visible, limited, reviewable, and removable before an AI workflow becomes part of the office’s critical operations.
Sources:
- https://learn.microsoft.com/en-us/security/zero-trust/sfi/higher-security-microsoft-entra-id-apps
- https://learn.microsoft.com/en-us/entra/fundamentals/zero-trust-protect-identities
- https://www.nist.gov/itl/ai-risk-management-framework
- https://www.cisa.gov/ai