Topic starter
11/11/2026 6:05 pm
TL;DR: AI agents can outgrow standing role permissions because a single workflow may span tools, APIs and MCP servers, according to IndyKite. Authorization has to follow the approved task in real time, or broad access will outrun the work it was meant to support.
Editorial analysis by NHI Mgmt Group, based on content published by IndyKite: “Intent-based access control for AI agents”.
Key questions
Q: What is the difference between RBAC and intent-aware access for autonomous workflows?
A: RBAC assigns permissions by role, while intent-aware access evaluates the action, context, and sensitivity of the request before it executes.
Q: How should security teams design MCP server access for AI agents?
A: Security teams should design MCP access around a small set of agent goals, not a mirrored list of REST endpoints.
Q: How do you authorise an AI agent for a specific task?
A: Authorise an AI agent by tying each sensitive action to a named task, not just to a role or account.
Practitioner guidance
- Define task-scoped authorisation for agents Map each agent workflow to the smallest set of actions needed for a named objective, then require the system to validate that objective before every sensitive step.
- Bind delegation chains to original intent Preserve the initiating user purpose across handoffs so downstream agents cannot widen access beyond the original task.
- Treat MCP tool discovery as untrusted capability Require policy checks before a discovered tool can be used, even when the server makes the tool available to the agent.
Bottom line: AI agents change the authorization problem because they can alter tools, data paths and execution state while still operating under the same identity.
Glossary terms: Intent-Based Access Control, Role-Based Access Control, MCP, Delegation Chain
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/11/2026 6:06 pm
Standing roles are the wrong control boundary for autonomous work: AI agents do not stay inside a single access pattern long enough for role design alone to describe their real authority. A task can span multiple systems, shift tool choice midstream and require different data at different points. The practical implication is that authorization has to follow execution, not just assignment.
A few things that frame the scale:
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Why do AI agents need separate runtime authentication and authorisation controls?
A: Because agent governance answers who approved the agent and what it should do, while runtime controls decide whether the agent can actually act in a specific system. Without enforcement at the access layer, policy can describe boundaries that the live agent never has to obey. That is a direct production risk.
👉 Read our full editorial: Intent-based access control adds context to autonomous agent decisions