Should organisations change identity and access controls for AI-enabled apps?

Yes, when AI features fetch data, call tools, or act on behalf of users or the application, access control must cover those machine-mediated paths. That means limiting privileges, scoping data access tightly, and reviewing delegated access with the same discipline used for other non-human workflows.

How AI-enabled apps change the access-control problem

AI-enabled apps are not just another user interface layer. When they retrieve data, invoke tools, trigger workflows, or take action for a person or a service, they create machine-mediated access paths that deserve explicit control. The control question shifts from “Can a user see this?” to “What can this feature access, on whose behalf, and with what limits?”

The practical consequence is that identity and access design must cover the model or agent path, the tool path, and the underlying data path together. If those paths are treated separately, an application can appear compliant at the UI while still being over-permissive in retrieval, API calls, or delegated actions behind the scenes.

That is why scoped permissions, task-specific access, and reviewable delegation matter more than simple login protection. An AI feature may be trusted to answer a question, but not to browse an entire repository, execute a write action, or reuse a user’s broad entitlements without a narrower policy decision.

What should change in permissions, delegation, and data scope?

Start by separating three things: the human user’s identity, the application’s own runtime identity, and any agent or tool identity used to fetch, transform, or act. Each should have the minimum access needed for its role. Where the AI feature acts on behalf of a user, the delegation should be explicit, bounded, and traceable rather than implied by a shared session or blanket token.

This is where Authorisation Models Guide is useful, because AI-enabled apps often need more than coarse role-based access. Attribute, relationship, or policy-based decisions are often a better fit when access must depend on document sensitivity, task context, tenant boundaries, or the specific action being requested.

Data scope should be narrowed at the point of retrieval, not only at the point of display. If a feature can query everything and then filter later, the system has already exposed too much. The safer pattern is to enforce permissions before retrieval, before tool invocation, and before any write-back or side effect. The same logic applies to secrets, connectors, and downstream APIs, which should be reachable only through tightly scoped service credentials.

For teams dealing with broader identity governance, IAM and IGA Basics helps frame the lifecycle side of this problem. AI-enabled access should be inventoried, owned, reviewed, and recertified like any other privileged path, especially when the app can reach production systems, customer data, or shared knowledge stores.

Which AI access paths create the most hidden exposure?

The highest-risk paths are usually the ones that feel “automatic” to developers: background retrieval, connector access, workflow automation, and tool invocation. These paths often inherit too much from the parent application, then amplify it through scale. A feature that is harmless for one user can become a broad exfiltration or misuse route if it runs against many identities, tenants, or records without per-request constraints.

Permission-Aware RAG Guide is directly relevant when the AI feature retrieves internal content, because retrieval-layer over-sharing is one of the easiest ways to leak data. The same issue appears in tool use: if the agent can call a ticketing system, cloud API, or database connector with the wrong token, the model can surface or modify data it should never have seen.

Delegated action creates a second hidden risk: the app may perform a legitimate action, but with broader authority than the user intended. That is especially important for write operations, approvals, account changes, purchasing, and administrative workflows. If the system cannot clearly show what it is about to do, what policy allowed it, and what identity it used, the control is too weak for production use.

AI Agent Authorisation Guide is a strong fit for that delegated-action problem, because AI agents should receive task-scoped and just-in-time access rather than standing authority. For apps that use autonomous or semi-autonomous features, this helps reduce blast radius when the agent is wrong, manipulated, or simply overconfident.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-9 — Identification and Authentication (Service and Non-Organizational Users)	AI apps and agents often authenticate as services or workloads.
	AC-6 — Least Privilege	AI-enabled apps should only access data and tools needed for the task.
	AU-6 — Audit Record Review, Analysis, and Reporting	Delegated AI actions need reviewable evidence of what was accessed or changed.
Recommendation — Use IA-9 to require strong non-user authentication for AI services and connectors. Apply AC-6 to constrain AI feature and tool permissions to the minimum necessary. Use AU-6 to monitor and review AI-mediated access and actions.
ISO/IEC 27001:2022	A.5.15 — Access control	AI-enabled access decisions require explicit policy boundaries and enforcement.
	A.8.2 — Privileged access rights	AI features can become privileged actors if they can call tools or write data.
Recommendation — Apply A.5.15 to define and enforce access rules for AI-mediated paths. Restrict A.8.2 privileges for AI services, connectors, and delegated workflows.
CIS Controls v8	CIS-6 — Access Control Management	The question is about tightening who and what can reach data and actions.
Recommendation — Use CIS-6 to inventory and limit AI-enabled access paths and entitlements.
OWASP ASVS	V8 — Authorization	AI-enabled apps must authorise retrieval and actions, not only user sessions.
Recommendation — Apply V8 to verify every AI-mediated request is authorised before execution.
OWASP API Security Top 10	API5 — Broken Function Level Authorization	AI tools and service calls can bypass intended function-level restrictions.
	API1 — Broken Object Level Authorization	Retrieval paths can expose objects or records beyond the intended user scope.
Recommendation — Use API5 to prevent AI features from invoking functions they should not reach. Apply API1 to enforce object-level checks on AI retrieval and tool access.

Practitioner Guidance

What to prioritise: Review any AI feature that can read, fetch, or write data outside the visible user interface. If it can touch a sensitive system, treat its permissions as production access, not experimentation access.

What to verify: Confirm that retrieval, tool calls, and side effects are authorised before execution, not after the model has already acted. Verify that service tokens, connector permissions, and delegated scopes are narrower than the parent user or application account.

Common mistake: Teams often secure the chatbot front end but leave the backend integration path broadly privileged. That creates a false sense of safety, because the model can still become the fastest route to overexposure or unauthorized action.

What good looks like: Each AI-mediated action is attributable to a specific user, application, or agent identity, and each path has a clear policy boundary. Access is limited to the minimum data and the minimum action needed for the task, with review points for privileged or persistent delegation.

Practitioner takeaway: If an AI-enabled app can make decisions or take actions, the access model must be built around those machine-mediated pathways, not just around human login events.