Notifications
Clear all
Topic starter
24/06/2026 9:10 pm
TL;DR: As AI and LLM systems connect to larger internal data and tool surfaces, authorization and access control failures become more likely to create exposure and compliance problems, according to PlainID’s analysis. The practical shift is from protecting a single app to governing prompts, data queries, tool access, and response masking as one policy boundary.
NHIMG editorial — based on content published by PlainID: Best Practices for Securing AI Systems with Authorization
By the numbers:
- 50% of cybersecurity attacks will stem from insufficient or improperly implemented access controls.
Questions worth separating out
Q: How should security teams govern AI systems that access internal data and tools?
A: They should treat the AI path as an authorization workflow, not just an application feature.
Q: When do AI access controls fail in practice?
A: They fail when authorization happens after retrieval, when tool permissions are broad, or when response masking is treated as optional.
Q: Why do AI systems complicate existing IAM and data protection models?
A: AI systems can combine human intent, application logic, and machine access in a single runtime flow.
Practitioner guidance
- Map AI workflows to existing entitlement sources Inventory which prompts, retrieval paths, tools, and output channels depend on which identities and permissions.
- Enforce source-side filtering for retrieval Apply access checks before documents are returned to the model context, not after generation.
- Separate tool authorization from model reasoning Define which services and APIs an AI system may call through policy, not through implicit application logic.
What's in the full article
PlainID's full blog post covers the operational detail this post intentionally leaves for the source:
- A four-point AI control model that shows how to place policy checks across prompts, retrieval, tools, and masking
- The article's own explanation of how identity-first and zero-trust principles apply to AI workflow authorization
- Plain-language examples of where to enforce access at source instead of after the model has already processed data
- The vendor's framing of policy management across the full AI workflow for teams building or updating controls
👉 Read PlainID’s guidance on authorization controls for AI systems →
AI system access controls: what IAM teams need to get right?
Explore further
25/06/2026 6:13 am
AI authorization is becoming an identity architecture problem, not a model-risk side issue. Once an AI system can query internal data and invoke tools, the security boundary shifts from the model to the policy layer that decides what the system may touch. That means the same access governance questions that apply to service accounts and privileged workflows now apply to AI mediation paths. Practitioners should treat AI authorization as part of the core IAM control plane, not as an overlay.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How do teams decide whether AI masking and filtering are enough?
A: They are enough only if they are enforced before exposure and aligned to identity-specific policy. A control that hides data after it has already been retrieved or processed does not prevent access, it only limits what is shown. Teams should verify where the control sits in the request chain and whether it blocks disclosure at the source.
👉 Read our full editorial: AI system authorization controls are the new security baseline
