← All insights

Current cybersecurity development

Cybersecurity’s Next Shift: More Identities, More Automation, More Governance

Current security guidance increasingly focuses on non-human identities, AI-enabled workflows, and the need to govern what automated systems can access.

Business technology team discussing responsible automation and identity governance in a modern office

The development business leaders should watch

Cybersecurity is moving beyond the traditional question of which employees can log in. Businesses now use cloud applications, integrations, service accounts, automation tools, and increasingly capable AI features. These systems may read documents, send messages, create records, or trigger actions on behalf of people.

Microsoft’s 2026 security reporting describes identity as a growing pressure point because the access environment includes human, non-human, and agentic identities. Microsoft has also announced products and previews intended to govern AI agents through organizational policy and identity. These announcements describe vendor capabilities and direction; they do not prove that a particular product is appropriate, secure, or generally available for every small business.

What is confirmed

The confirmed security principle is straightforward: every identity should have only the access it needs, for only as long as it needs it, with activity logged and reviewed. That applies to employees, vendors, applications, service principals, automation accounts, and AI-assisted tools.

The uncertain part is the maturity and behavior of emerging tools. Product names, licensing, preview status, integration limits, data-handling terms, and security controls can change. Businesses should verify current documentation before enabling a new capability or placing sensitive information into it.

Why automation changes the risk

A human user may open one file or send one message. An automated tool can process thousands of records quickly. If its permissions are too broad, a configuration error or compromised token may create a larger incident than a single-user mistake.

Automation can also make responsibility unclear. If an AI assistant drafts a customer response, updates a database, or summarizes confidential files, the business must know:

  • What information the system can access.
  • Whether submitted data is retained or used for model improvement.
  • Which identity performs the action.
  • Whether a human approves the result.
  • How activity is logged.
  • How access is revoked.
  • What happens if the service is unavailable.

Do not assume that an AI feature inherits every control from the surrounding application. Review the vendor’s documentation and contract.

Establish an identity inventory

Add non-human accounts to the same inventory used for employees and devices. Record:

  • Service accounts and application registrations.
  • API keys, certificates, tokens, and secrets.
  • Owners and business purposes.
  • Systems and data accessible to each identity.
  • Expiration and rotation dates.
  • Logging and alerting coverage.
  • The process for disabling the identity.

Remove abandoned integrations. A forgotten application consent or old service account can provide a quiet path into important data.

Use least privilege for AI and automation

Begin with low-risk tasks and limited datasets. Avoid granting a new tool access to an entire mailbox, shared drive, customer database, or accounting system when a narrow folder or test dataset will answer the business question.

Use separate environments for experimentation and production. Require human approval before automated systems send external communications, change payment information, delete records, or make decisions affecting customers or employees. Keep audit logs and review unusual volume or behavior.

These controls do not reject automation. They make it easier to learn safely before the tool becomes deeply embedded in business operations.

Watch for supply-chain and vendor exposure

A business may be affected by a security event at a software provider, identity platform, payroll company, or managed service provider. Review contractual notification terms and understand which logs, backups, and response services the vendor provides.

Ask whether the vendor supports MFA, scoped permissions, administrative logging, secure development, vulnerability disclosure, incident response, data deletion, and export of business records. Ask specifically what is included in the customer’s responsibility.

Avoid exaggerated claims

Current cybersecurity discussions often mix confirmed incidents, vendor announcements, research findings, and forecasts. Separate them:

  • Confirmed: a vendor advisory, official investigation, or documented product behavior.
  • Likely: an expert assessment supported by technical evidence but not fully established for every organization.
  • Uncertain: a prediction, preview capability, or claim requiring additional verification.

This discipline matters because rushed responses can create new risk—such as enabling excessive monitoring, uploading sensitive data to an unapproved service, or purchasing a tool without a recovery plan.

A cautious adoption process

  • Name the business purpose and data involved.
  • Identify the human and non-human identities required.
  • Test with synthetic or low-sensitivity information.
  • Limit permissions and require MFA for administrators.
  • Document retention, logging, approval, and shutdown procedures.
  • Review vendor terms and security documentation.
  • Train employees on acceptable use and reporting.
  • Reassess after significant product or workflow changes.

The next phase of cybersecurity will not be only about defending devices. It will be about governing access, automation, data movement, and accountability. Central Florida businesses can benefit from new tools while reducing risk by starting small, limiting permissions, and requiring evidence before expanding use.

Human-reviewed draft. Guidance is general information, not legal advice.

Sources