TL;DR: AWS’s February 2026 permission changes shifted cloud privilege risk toward model integrity, because a new Bedrock Mantle fine-tuning action can alter model behaviour rather than just data access, according to Sonrai Security. The governance problem is that access reviews and least-privilege models still assume static, reviewable entitlements, while model-shaping permissions can create persistence and defence evasion paths inside AI workflows.
NHIMG editorial — based on content published by Sonrai Security: Feb Recap. New AWS Privileged Permissions and Services
By the numbers:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
Questions worth separating out
Q: How should security teams govern permissions that can change AI model behaviour?
A: Treat those permissions as privileged access, not ordinary application functions.
Q: Why do model fine-tuning permissions create a bigger risk than ordinary cloud permissions?
A: Because the impact can persist after the session ends.
Q: What breaks when AI permissions are reviewed like standard DevOps access?
A: Review cycles miss the fact that some AI permissions are not transient.
Practitioner guidance
- Reclassify model-training permissions as privileged access Inventory every permission that can create, modify, or retrain AI models and place it under PAM review, approval, and logging.
- Separate training rights from observability rights Split permissions that can write to model pipelines from permissions that can read deep telemetry or configuration data.
- Require provenance for every fine-tuning input Track who supplied the dataset, which identity approved the job, and whether the source data was vetted for poisoning or prompt-injection content.
What's in the full article
Sonrai Security's full blog post covers the operational detail this post intentionally leaves for the source:
- The specific AWS permission names and why each one is considered privileged in cloud identity terms.
- The monthly permission-by-permission breakdown that shows where AI and infrastructure risk is moving inside AWS.
- The MITRE ATT&CK mapping used to classify model-poisoning and telemetry exposure paths.
- The product context around Cloud Permissions Firewall and how it flags newly risky permissions in practice.
👉 Read Sonrai Security's analysis of new AWS privileged permissions and model risk →
AWS Bedrock fine-tuning permissions: what IAM teams need to know?
Explore further
Model-integrity permissions are privileged access, even when they do not look like classic admin rights. The cloud security habit of separating “dangerous” from “routine” permissions breaks down once a permission can alter model behaviour, training data, or safety filters. That means identity governance has to classify AI training actions as a privileged control surface, not a feature toggle. Practitioners should treat model-shaping rights as part of the privileged access estate.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI, even as 53% expect AI to run major portions of infrastructure autonomously within three years.
A question worth separating out:
Q: Which controls should organisations use for AI training and telemetry access?
A: Use separate approval paths, tight role scoping, provenance checks, and explicit rollback rules. Training rights should not travel with broad telemetry access, because both can be abused in different ways. The goal is to prevent model manipulation from hiding inside routine operational permissions.
👉 Read our full editorial: AWS model fine-tuning permissions are becoming a privilege risk