Month: October 2026

One compromised cloud key can give an attacker far more access than a workload needs. Excessive permissions can turn a stolen credential, vulnerable service or pipeline error into a wider incident. Operationalising least privilege means keeping access limited as systems change, not cleaning up permissions once and moving on.

Manual IAM reviews often fall behind new applications, cloud resources and machine identities. A CI/CD pipeline can catch risky permission changes alongside code changes, then help teams make safe, traceable fixes.

Start with a clear identity inventory, use activity data to shape narrower policies, and add checks that fit your delivery process. Track whether access is shrinking over time. NIST SP 800-53 Rev. 5 control AC-6 sets out the principle: grant users and processes only the access they need to do their work.

Establish an IAM baseline before automating changes

Automation needs reliable data. Without a clear view of identities, access and ownership, a tool may miss a risky grant or recommend a change that disrupts a service. Build an inventory first, then rank findings by risk.

Map human, workload and pipeline identities

Include cloud roles, service accounts, deployment credentials, CI runners, third-party integrations and human administrator accounts. Give each identity a named owner, a clear purpose, an environment and a review date. These details help teams decide who should assess a finding and whether access still fits the identity’s role.

Find risky grants and set a baseline

Look for broad permissions, unused access, long-lived credentials and grants that cross development, test and production boundaries. Prioritise identities with production access, powerful administrative actions or no clear owner. Record starting measures, such as identities with unused permissions, wildcard actions, long-lived keys and overdue exceptions. Those figures show whether remediation is reducing risk.

Right-size IAM permissions using evidence

Permission changes should reflect both policy intent and observed activity. Logs can show what a workload has done, but they may not capture a rare backup, deployment or recovery task. Treat usage data as evidence for review, not a complete list of future needs.

Collect permission-use evidence across environments

Use cloud audit logs, IAM last-accessed data, access analysers and application telemetry to see which actions identities use. Compare development, staging and production separately; a production service may handle tasks that never occur in a test environment. Check scheduled jobs and infrequent tasks over a suitable observation period before removing access.

Propose narrower policies and test them

Compare current permissions with observed actions, then draft a policy limited to the required actions and resources. AWS IAM Access Analyzer can help generate policies from CloudTrail activity and check policies for security issues. Review the result with the service owner, test it outside production, and check key workflows such as deployment, backup and incident response.

Keep emergency access separate

Routine workload roles should not hold broad emergency permissions. Use time-bound elevation with explicit approval, audit logging and a review after use. This keeps exceptional access available without making it part of everyday operation.

Put IAM checks and remediation in the CI/CD pipeline

A pipeline can check proposed infrastructure changes before they reach production. Findings work best when they appear beside the code that caused them, with a clear reason and an owner who can act.

Scan IAM changes before release

Run infrastructure-as-code policy checks on pull requests and deployment plans. Flag broad actions, wildcard resources, privilege-escalation paths, public trust relationships and unapproved policy changes. AWS IAM Access Analyzer offers policy validation, while GitHub Actions OIDC documentation describes using identity federation to obtain short-lived cloud credentials instead of storing long-lived keys.

Make fixes reviewable and traceable

Have automation open a pull request to narrow a policy rather than silently changing live access. Include the affected workload, evidence for the change, expected behaviour, test results and a rollback plan. Reviewers can then assess both the security gain and the risk to the service.

Match enforcement to risk

Begin with reports or warnings while teams tune the rules. Block high-confidence violations once checks produce useful results. Keep exceptions explicit, assigned to an owner, time-limited and recorded; a permanent pipeline bypass can hide the same risk indefinitely.

Make automated IAM remediation safe and reversible

A permission reduction can break production if it removes access a service needs. Set safeguards based on the identity, environment and impact of the change, and make sure teams can restore the prior policy.

Require review for high-impact changes

Changes to production roles, administrator permissions or recovery operations need stronger review than a development role change. Require approval from the service owner and, where the risk warrants it, security. Record who approved the change and why.

Test behaviour and plan a rollback

Use unit and integration tests, then review the deployment plan before release. For suitable services, roll out the policy change gradually and watch for authorisation failures after deployment. Keep the previous policy version and document how to restore it so a failed change does not delay recovery.

Protect the remediation pipeline

The automation that changes IAM needs narrow permissions of its own. Use short-lived credentials, isolated runners and protected branches. Separate the account that proposes a sensitive change from the people who approve it, and require changes to be reviewed or signed before they reach production.

Measure progress and keep IAM policies current

More scans or pull requests do not prove that access is safer. Measure changes against the baseline and align review cycles with NIST SP 800-53 AC-6 and your organisation’s security and change-management policies.

Track whether access is getting narrower

Measure unused permissions removed, identities with named owners, wildcard grants remaining, time to remediate and the age of open exceptions. Track policy-related deployment failures as well. Compare results over time and by team or environment to spot both progress and gaps.

Reassess access as workloads change

Review permissions on a set schedule and when a role, integration, application or cloud design changes. Give exceptions an expiry date and an owner who must renew them. This stops temporary access from becoming a lasting grant by default.

Learn from failures and repeat findings

Authorisation failures, audit findings and repeated pipeline alerts can reveal gaps in templates, tests or developer guidance. Use those lessons to improve shared policies and remediation rules. Fix the cause without weakening controls across unrelated services.

Conclusion

Automated least privilege works when teams combine sound identity data, permission evidence, careful testing and accountable approvals. Put checks in pull requests, protect the credentials that run them, and measure whether unnecessary access falls.

Start with one production workload or deployment identity that has a clear owner and observable activity. Test the review, approval, rollback and measurement process, then extend it to other services. Detect access drift early, propose a tested fix and verify the result.

An attacker can use AI to draft a convincing message in minutes, while a security team may need hours to investigate one. AI is changing the economics and speed of cyberattacks by reducing effort in some routine tasks. It doesn’t make every attacker more skilled or every attack autonomous. But it can leave your organisation less time to spot trouble and act. The key test is whether your people, processes and controls can respond before an intruder reaches their goal.

How AI is changing the economics of cyberattacks

Routine tasks take less time

Generative AI can help attackers review public information, translate messages and write tailored emails. It can also produce basic scripts or adapt existing text for different targets. These tools speed up familiar tasks; they don’t prove that an attacker can run a complete operation without human input.

A fluent message may seem more plausible, especially when it uses details about a person or company. But good writing alone won’t bypass email filters or persuade every recipient. The result depends on the tool, the operator and the target.

Expertise still matters

AI assistance with common tasks is different from gaining access to a network or keeping it. Attackers still need to choose targets, work around defences and achieve a goal, such as stealing data or disrupting services. Those steps call for skills and judgement that a text generator can’t guarantee.

Tools also vary in quality, and operators may use them badly. A weak plan remains weak even when an AI tool helps draft its messages. Lower effort in one part of an attack doesn’t remove the other barriers.

Crime still depends on results

Saving time on research or message writing could improve an attacker’s return on effort. Yet that return still depends on whether someone clicks, whether access can be kept, and whether stolen data or funds can be turned into a gain. Detection can also cut an operation short.

There’s no sound basis for assigning a fixed saving to attackers across all cases. A faster start may help, but it doesn’t guarantee a successful attack or a profit.

Why AI can make cyberattacks faster

Reconnaissance and social engineering can speed up

AI tools can help sort through public material and shape messages for a particular person or team. That can shorten preparation time and make a request sound familiar. It doesn’t ensure that the message will get past technical checks or seem genuine to its recipient.

Attackers can also change wording quickly when an approach fails. For defenders, this makes it harder to rely on spotting one repeated phrase or format. Identity checks and reporting routes matter more than trying to predict every version of a message.

Slow reviews give intruders more time

High alert volumes, manual approvals and unclear escalation paths can delay a response. If a stolen account remains active while staff decide who owns the alert, an intruder has more time to act. A tool can raise a warning, but people still need a clear way to assess and contain it.

Measure the time between an alert and triage, then track how long it takes to isolate a device or disable a compromised account. These intervals show where your response stalls. They also give teams a practical way to test whether changes improve performance.

Familiar attack methods remain central

AI is an accelerator, not a new category of attack. Credential theft, software flaws and social engineering remain common ways into organisations. Controls against these methods still deserve attention.

The Verizon 2024 Data Breach Investigations Report found that exploitation of vulnerabilities as an initial access vector rose by 180% compared with the prior year. That finding is useful context for patching and exposure management; it is not evidence that AI caused the increase.

What real-world evidence says about AI attacks

AI tools have supported threat actors

OpenAI reported disrupting activity by state-affiliated groups that had used its tools for tasks such as research, translation, coding support and drafting. The report found no evidence that this use created significant new capabilities. It points to practical assistance, rather than proof of a major shift in what those groups could do.

This distinction matters for security planning. AI may help with parts of an operation without changing the attacker’s overall skill or success rate. Treat reported use as a reason to review controls, not as proof that every attack has become more advanced.

Deepfakes can make impersonation harder to spot

Hong Kong police reported a 2024 case in which an employee transferred about HK$200 million after a video call involving deepfake versions of colleagues. The incident shows the risk of trusting a face or voice as proof of identity. It doesn’t mean that AI is involved in every impersonation scam.

For sensitive requests, confirm the person through a separate, trusted channel. A familiar voice or live video should not replace approval steps for payments or changes to access.

Forecasts warn of growing pressure

The UK National Cyber Security Centre assessed that AI was likely to increase the volume and heighten the impact of cyberattacks over the following two years. This is an expert forecast, not a promise that every organisation will face a more severe incident. It does point to a need for teams to prepare for more activity and less time to review it.

How security controls can keep pace with cyberattacks

Strengthen identity and verification

Use phishing-resistant multifactor authentication where possible, and give staff only the access their roles require. Monitor for unusual sign-ins, such as unexpected locations or devices. These steps can limit what an attacker can do with a stolen password.

Set an independent check for payment requests and changes to bank or access details. Use a second channel and established approval rules, rather than trusting a voice or video call alone. Make sure staff know how to raise concerns quickly.

Close common entry points

Prioritise timely fixes for known vulnerabilities, especially on internet-facing systems. Secure configuration, email protections and endpoint monitoring can also reduce exposure or help spot suspicious activity. The Verizon DBIR finding on vulnerability exploitation reinforces the value of this work, regardless of whether AI played any role.

Test backups before an incident, and check that teams can restore critical services from them. A backup that hasn’t been tested may not help when a system is down. Keep recovery steps clear and assign responsibility in advance.

Measure detection and response times

Track how quickly your team detects suspicious activity, contains it and revokes compromised credentials. Measure recovery time for critical services as well. These figures show whether controls work together, not just whether each product is switched on.

Run realistic exercises that include a convincing impersonation or AI-assisted phishing attempt. Check when staff report it, how alerts reach the right team and how quickly accounts or devices can be secured. Use the delays you find to update your playbooks.

Use AI defensively, with clear limits

Automate repeatable work with oversight

Defensive tools can enrich alerts, group related events and summarise an investigation. Automation may also support routine response actions, such as opening a case or collecting relevant logs. Human review remains important when an action could lock out a user or disrupt a service.

Keep a record of automated decisions and review errors as well as successes. That gives your team a way to spot poor results and adjust the process. Don’t give a tool wider access than its job requires.

Set rules for approved AI use

Tell employees which AI tools they may use and what data they must keep out of them. Sensitive customer, staff or company information should only go into tools approved for that purpose. Set rules for checking generated code before it reaches production.

Staff also need a clear way to report suspicious messages or synthetic media. Simple guidance can help them pause, check the request through a trusted channel and report concerns without delay.

Rehearse the full response

Tabletop and technical exercises should test reporting, escalation, account lockout and device isolation. Include payment checks and service recovery, not only the first alert. A response plan is useful only if people can follow it under pressure.

After each exercise, record where time was lost and who needs to act next. Update the playbook, then test it again. Rehearsal turns assumptions about response speed into evidence.

Conclusion: Security speed matters as much as coverage

AI can make some attack tasks faster and easier to scale, but it doesn’t remove the need for skill or guarantee success. Familiar methods such as credential theft, vulnerability exploitation and impersonation still call for strong controls. Identity checks, timely patching, monitoring and tested recovery all reduce the chance that an attacker can act unchecked.

The real question is how quickly your organisation can respond when a request looks convincing and time matters. Test your people and controls, find the delays, and fix them before an incident forces the issue.