AI-assisted attacks: governing application access before an incident

On November 5, 2026, Microsoft reported that threat actors were using AI agents to find exposed credentials and pursue further access. In at least one observed case, an agent moved from searching GitHub to extracting data from Azure Key Vault in five minutes. That was one case, not an average or a universal response deadline. Microsoft had observed the search activity since August and certain subsequent actions since October 28. Microsoft's investigation

The Canadian Centre for Cyber Security's October 26 bulletin describes attacks that connect several stages with less human intervention. People still choose targets and objectives. Its recommendations include limiting application access and deciding in advance who can isolate an account, application or service. Canadian Cyber Centre bulletin

For an operations team, this raises a question that needs an answer before an alert arrives: if a connected application becomes unsafe to use, who can stop its access, and what work will stop with it?

Map the access that runs your process

A business integration may read a shared mailbox, retrieve documents and update another system without an employee signing in for every action. The organization needs to identify the application identities and permissions behind those connections, alongside its employee accounts.

Microsoft's investigation includes misuse of valid application credentials across connected cloud resources. Removing an exposed secret from a repository does not invalidate copies that an attacker may already hold. The response must invalidate the exposed credential. Microsoft: application credential exposure

Start with the records your team already has: approved integrations, vendor agreements and system access reviews. For each connection, identify its business purpose and compare the access it has with the access that purpose requires. An integration intended to read one document folder should prompt a specific review if its permissions reach a whole workspace.

Record where the team can verify the configuration. A description such as “connects customer service to the CRM” leaves several questions unanswered. Which mailbox can it read? Which CRM records can it change? Does it use your organization's identity or a vendor-managed application? Who can change that access?

Give one integration a usable access record

Consider a proposed customer-service connector that reads a shared inbox and creates or updates cases in a CRM. The following example is fictional. It has not been implemented or tested for this article.

An access record for this connector could look like this:

The table is a starting point for a discussion between operations, IT and the people responsible for security. A team should replace the example roles with its own accountable people and verify that their authority matches the incident plan.

Agree what happens when the connection is paused

In this example, the support inbox remains the source of incoming requests, provided responders confirm it is safe for staff to use. If the connector is paused, the operations team needs an approved way to record which messages have been handled. Otherwise, a later restart could create duplicate cases or leave some messages unprocessed.

Define this fallback while the process is working. Specify who uses it, what information they may handle and where they record completed work. Check that the fallback does not depend on the same identity or connection being investigated.

The containment decision also needs a backup owner. A document that names only one unavailable administrator will not explain what the rest of the team may do. Include an escalation path and the conditions under which a designated person can act without waiting for the usual owner.

Use the organization's incident-response process to determine the action. An alert may require investigation, a narrower access restriction or immediate isolation. The access record should help the authorized responders understand the operational consequences while they decide.

Verify what the access change actually stopped

Revoking a credential, disabling an application and removing a permission are different actions. The response procedure should identify which action applies to the affected connection and how the team will confirm its effect.

For Microsoft Entra applications, revoking a credential prevents new tokens from being issued with it, but some resources may continue accepting tokens already issued until they expire. Microsoft Entra guidance on revoked credentials

Ask each provider which controls affect existing access, how quickly they take effect and what evidence shows that the unwanted access has ended. A successful configuration change is one observation; the investigation also needs to examine activity against the connected resources.

For a rehearsal, use a test environment and synthetic records. Have the designated administrator carry out the approved restriction, then check what the connector can still do. Record the result, including any access that continues and any unexpected effect on another process. This exercise should be planned with the security team and the relevant system owners.

Restore access with a record of interrupted work

Restoring a connection involves both a security decision and an operational check. NIST's 2025 incident-response guidance includes recovery authorizations and confirmation with system owners that restoration has succeeded. NIST SP 800-61 Rev. 3

The incident lead should define the conditions for restoring access. The process owner should account for work completed, queued or left uncertain during the interruption.

Once the incident lead has authorized a controlled restart, compare the support inbox with the CRM before replaying queued messages. Identify cases already created, messages handled through the fallback and requests that still need attention. Test a limited batch and inspect the results before returning to the normal volume.

Keep the evidence needed to explain who authorized the restriction, what changed and who approved restoration. Apply the organization's access and retention rules to those records. The record can point to protected logs or case files without copying confidential content into a general worksheet.

The team's review should include the interruption's effect on customers and staff. Time to restrict access is one measure. It also matters whether the team identified affected work, avoided duplicates and restored the process within the conditions set by the incident lead.

Start with a connection your team depends on

Choose one integration that moves business information between systems. Ask its process owner and technical owner to walk through its access record together. Have them identify who can restrict it, how work continues and what must be checked before it returns.

DezoTech helps operations and IT teams map workflows, system dependencies and responsibilities. If an integration's access or ownership is unclear, discuss a workflow with DezoTech. That mapping can support the work of the security specialists responsible for incident investigation and response.