← All insights

Current cybersecurity development

The Security Cost of AI Agents Is an Access-Management Problem

AI-enabled tools are moving into ordinary business workflows. The confirmed security issue is not science fiction; it is the need to govern what automated identities can access and do.

Office manager reviewing an AI workflow approval plan on a laptop

What is confirmed

AI-enabled assistants and automated agents are moving from experimentation into business applications. Microsoft’s 2026 security updates describe new controls for agent identity, authorization, execution environments, and auditing. NIST has also continued updating Cybersecurity Framework resources, including a 2026 quick-start guide connecting cybersecurity, enterprise risk management, and workforce management.

These developments confirm a direction of travel: organizations will manage more non-human identities alongside employee accounts. They do not prove that every small business needs a complex autonomous-agent platform today, nor do they establish that AI tools are inherently unsafe.

Why ordinary office workflows are affected

An AI-enabled tool may read email, summarize documents, draft responses, search a file repository, create tasks, or call another service through an application programming interface. If it has broad permissions, a mistaken instruction, malicious document, compromised account, or poorly designed integration can produce consequences at machine speed.

The security question is therefore specific: What can the tool access, under whose authority, for what purpose, and how can the business stop or review it?

This applies to more than tools marketed as “agents.” It includes browser extensions, workflow automation, customer-service bots, meeting assistants, document processors, and integrations that use stored credentials or delegated permissions.

A practical approval process

Before enabling an AI or automation feature, require the requestor to document:

  • The business purpose and expected benefit.
  • The data the tool will read, create, transmit, or retain.
  • The human or department responsible for approving outputs.
  • The identities and permissions the tool requires.
  • Whether data is used for model training or shared with another provider.
  • How access is revoked and data is deleted when the trial ends.
  • What logs, alerts, and vendor notifications are available.

Do not approve an integration merely because it is available in an existing software marketplace. Marketplace availability is not a substitute for reviewing data flows, permissions, retention, contract terms, and incident procedures.

Start with least privilege

Give the automation the smallest useful permission set. Prefer read-only access for pilots. Limit it to a defined site, mailbox, folder, or dataset. Separate testing from production. Use a dedicated identity rather than a staff member’s personal account when the platform supports it. Require MFA and protect the credentials or tokens used by the integration.

Set expiration dates for pilot access. Review application consent and delegated permissions. Remove unused integrations. Monitor for unusual volume, unexpected destinations, or actions outside the approved workflow.

Keep a human in the loop where harm is possible

Automated output should not independently approve payments, change payroll, disclose confidential client information, alter legal or clinical records, or make high-impact decisions without appropriate review. A human review step is not a guarantee, but it creates a point at which errors and suspicious instructions can be caught.

Train employees to treat AI-generated text as unverified content. It may contain incorrect facts, reveal sensitive information, or follow instructions embedded in a document that the user did not intend to authorize. Establish rules for what information may be entered into public or consumer AI services.

What remains uncertain

AI products change quickly. Names, licensing, retention terms, security controls, and administrative settings can change between releases. Vendor claims may describe a product’s intended design rather than your tenant’s actual configuration. Regulatory requirements for particular AI uses also depend on industry, location, data type, and use case.

For that reason, record the product version or service date, approved settings, data classification, and review date. Reassess when the vendor adds new capabilities or the business expands the tool’s permissions.

A 30-day starting plan

During week one, identify every AI and automation tool already in use, including unsanctioned browser extensions and personal accounts. During week two, classify the data each tool handles and remove unnecessary permissions. During week three, establish an approval form and pilot one low-risk workflow with logging. During week four, review the results, revoke unused access, and decide whether the tool belongs in production.

The mature approach is neither unrestricted adoption nor blanket rejection. It is governed experimentation: clear purpose, limited access, accountable ownership, observable activity, and a reliable way to stop the system.

Every article remains a human-reviewed draft. This article is educational and does not replace legal, regulatory, insurance, or technical advice.

Sources