Identity Is the New Security Perimeter: Four Lessons From This Week’s Cyber News

The latest identity and access stories carry a clear message for business leaders: attackers are no longer focused only on breaking into networks. They are looking for trusted identities, cloud permissions, recovery processes and automated systems that can act at speed.

For small and mid-sized organisations, that does not mean buying every new security product. It means tightening the controls around who, what and how systems are allowed to access business data.

1. A compromised cloud identity can cause damage in minutes

Late-September reporting on Microsoft’s investigation into the Storm-3168 activity showed how stolen or exposed service principals can be used to move through a cloud environment quickly. The activity involved Azure discovery, destructive operations against storage and application resources, attempts to access storage keys and efforts to interfere with recovery controls.

Microsoft said the attacker used compromised workload identities rather than relying on a conventional hands-on keyboard intrusion. In the reported case, more than 100 storage deletion attempts were made during a destructive burst lasting roughly seven minutes. Some deletion attempts were blocked by resource locks and storage protection, demonstrating the value of independent recovery safeguards.

The incident is particularly relevant to organisations using Microsoft Azure, Microsoft 365 or other cloud platforms. Service principals, application registrations, automation accounts and API keys are often created to keep systems connected. They can also accumulate permissions long after the original project has changed.

For a smaller business, the risk is not limited to a sophisticated nation-state operation. A leaked secret in a repository, an overlooked automation account or an over-permissioned application can create a similar path to data loss, service disruption or a large recovery bill.

What businesses should do

• Create an inventory of service principals, application registrations, automation accounts and other non-human identities.
• Remove unused accounts and rotate secrets that have been exposed, shared informally or stored in code.
• Apply least privilege to workload identities. An account that reads customer data should not automatically be able to delete storage, alter backups or change security settings.
• Protect recovery resources with separate permissions, resource locks, immutable backups and administrator approval for destructive actions.
• Monitor unusual identity behaviour, including sudden resource enumeration, mass deletion attempts, new credential access and activity from unfamiliar locations.

A useful starting point is the Microsoft Security investigation, which describes how compromised service principals were used in the Azure environment. citeturn1search1

2. AI agents are becoming identity and access management problems

On September 29, RSA announced Agent ID, a platform designed to discover, register and govern AI agents in regulated and high-assurance environments. The launch reflects a wider industry shift: AI systems are no longer just tools that generate text or summaries. Increasingly, they can call applications, retrieve data, create records and trigger operational actions.

The immediate business challenge is visibility. An employee may connect an AI assistant to a SaaS platform, build an internal workflow or deploy an agent through a developer tool without the security team having a complete record of what the agent can reach. These systems may use service accounts, API tokens or delegated permissions that are difficult to trace back to a responsible person.

The core identity question is simple: who authorised the agent, what is it allowed to do, which data can it access and how quickly can that access be withdrawn?

This matters even if an organisation is not building advanced autonomous systems. AI features are appearing in customer support platforms, accounting software, CRM systems, developer tools and productivity suites. Every connection expands the access-management surface.

The RSA announcement describes capabilities for finding agents, assigning ownership, recording risk and governing agent activity across its identity platform. The product announcement is vendor-led, so businesses should treat it as a signal of market direction rather than as a reason to purchase immediately. citeturn1search0

What businesses should do

• Keep an inventory of approved AI tools, integrations, agents, plugins and automation workflows.
• Assign a named business owner and technical owner to every agent or AI-enabled workflow.
• Give agents task-specific permissions rather than broad standing access.
• Require approval before an agent can send external communications, change financial records, delete data or alter security settings.
• Log prompts, tool calls, data access and administrative actions where the platform supports it.
• Include AI agents in employee offboarding, vendor reviews and access recertification processes.

The practical lesson is that AI governance should not sit entirely with innovation or marketing teams. If an AI system can access business information or act on behalf of staff, it belongs within identity governance and security oversight.

3. Cloud AI components can expose credentials if they are treated like ordinary software

A separate story this week focused on vulnerabilities in the Amazon Bedrock AgentCore Python SDK. Security researchers reported that flaws in the Code Interpreter package installation helper could allow crafted package names to execute commands inside an AI sandbox and potentially reach credentials attached to the workload.

The issues were tracked as CVE-2026-12530 and CVE-2026-16796. AWS advisories state that the affected versions were addressed in bedrock-agentcore 1.6.1 and 1.18.1 respectively. The later fix addressed a bypass of the earlier protection. Organisations using affected versions, forks or derivative code should review the AWS security bulletins and the researcher disclosure before deciding whether further action is required. citeturn2search0turn2search2

The broader point extends beyond AWS. AI development frameworks often connect models to code execution, storage, databases, APIs and cloud roles. A vulnerability in a helper function can therefore become an identity problem if the running workload has access to sensitive credentials.

For a small organisation experimenting with AI, this can be easy to overlook. A developer may attach a role that is convenient during testing, then carry it into production. A proof-of-concept agent may receive access to an internal database, customer files or cloud storage without a proper review of what it really needs.

What businesses should do

• Identify every AI development framework, SDK and agent runtime used by staff or contractors.
• Patch affected components promptly and verify that application forks or pinned dependencies include the fixed versions.
• Do not pass user-controlled or model-generated package names, commands or file paths into execution environments without strict validation.
• Use short-lived credentials and narrowly scoped execution roles for AI workloads.
• Separate development, testing and production environments, with different accounts and permissions.
• Review cloud logs for unusual agent activity, credential retrieval, package installation and outbound connections.

The risk is not that every AI agent will become an attacker. The risk is that a trusted automation path can give a vulnerable component more authority than it needs. Least privilege remains one of the most effective and affordable controls available.

4. Phishing is becoming more convincing because attackers are borrowing trusted identities

A report published on October 1 described a campaign in which China-linked actors allegedly impersonated AI experts, including a former US official, to target people working in universities, think tanks and other organisations. Reporting based on Proofpoint research said the attackers used the identities and interests of trusted figures to support email-based targeting.

This is a familiar attack pattern with a more credible wrapper. Instead of sending an obviously suspicious message, attackers build trust around a person, event, policy discussion or industry relationship. The goal may be to steal credentials, access email or persuade a target to open a document or follow a login prompt.

Small and mid-sized businesses are exposed to the same technique. An attacker does not need to impersonate a government official. They may pretend to be a supplier, accountant, director, technology provider or existing customer. If the message arrives during a busy period and matches an expected transaction, normal caution can disappear.

Identity security is therefore also a communications and process issue. Strong authentication helps, but it does not remove the need for payment verification, careful handling of unusual requests and clear escalation paths.

What businesses should do

• Require phishing-resistant MFA, such as passkeys or security keys, for administrators, finance staff and other high-risk roles where practical.
• Configure conditional access to consider device health, location, sign-in risk and the sensitivity of the requested application.
• Train staff to verify unusual requests through a separate channel, especially bank-detail changes, urgent payments and password-reset instructions.
• Protect email accounts with anti-phishing controls, impersonation detection and reporting mechanisms.
• Review mailbox rules, OAuth grants, forwarding settings and recently registered applications after a suspected compromise.
• Make account recovery as secure as initial login. Help-desk staff should not be able to bypass identity controls based only on information available from email or social media.

The recent reporting on the impersonation campaign is a reminder that identity attacks often begin with social engineering rather than technical exploitation. citeturn1search5

The zero trust lesson: verify continuously, not just at login

These stories point in the same direction. Zero trust is not a single product or a network redesign project reserved for large enterprises. It is a method for reducing the damage caused when credentials, devices, applications or automation accounts are compromised.

A zero trust approach asks for evidence before access is granted and continues evaluating that access as circumstances change. Is the user on a managed device? Is the application behaving normally? Is the request consistent with the person’s role? Does the service account need this permission now? Can the action be reversed if something goes wrong?

For an Australian business, a practical zero trust program can start with identity hygiene rather than a major technology overhaul. Consolidating user accounts, enforcing MFA, removing stale access and improving logging will often deliver more immediate value than buying a complex platform without cleaning up the basics.

A realistic 30-day action plan

• Week one: list critical systems, administrators, service accounts, AI tools and external connections.
• Week two: remove dormant accounts, review privileged access and rotate exposed or long-lived secrets.
• Week three: enforce MFA for all staff, prioritising administrators, finance, remote access and cloud consoles.
• Week four: test backup restoration, review identity logs and run a short phishing and incident-response exercise.

Businesses that have more time and budget can then move towards automated provisioning and deprovisioning, privileged access management, device-based access policies, just-in-time administration and centralised identity monitoring.

What This Means For Your Business

The most important development this week is not one particular product launch or vulnerability. It is the convergence of human identities, machine identities and AI identities. Each can now access systems, make decisions and trigger business activity, sometimes at a speed that makes manual oversight impossible.

Business leaders should ask for a clear answer to four questions: who has access, why do they have it, what can they do and how quickly can access be stopped? Those questions should apply to employees, contractors, applications, automation accounts and AI agents alike.

Start with the controls that reduce risk quickly. Enforce strong MFA, remove unnecessary permissions, protect recovery systems, patch cloud and AI components, monitor unusual activity and rehearse what happens when an account is compromised. These measures are practical for smaller organisations and create a stronger foundation for future zero trust improvements.

Identity security is no longer just an IT administration task. It is part of business continuity, customer trust and operational resilience. The organisations that treat access as a continuously managed business risk will be better placed to adopt cloud automation and AI without giving attackers an open door.

Call Webwire on 08 9386 0053 or contact us at enquiries@webwire.com.au.