Your AI Agent Can Reach More Than Its Granted Permissions

Kiran Elengickal | Vice President at Siemba | AI, Cybersecurity, GTM Expert | Strategic Growth | Alliances | Innovation Leader.

​An AI agent’s access list records what it was granted. For AI agent security, the number that matters is what the agent can get other systems to do for it.

Consider an analytics agent approved for two sales datasets and nothing else. Its approval list is short and easy to defend. Elsewhere in the same environment runs a shared data-movement service, built so that nobody had to configure each integration individually, which executes requests under a privileged service account. The agent needs no elevated rights of its own. It needs to find that service and word a request the service will accept. Hidden text in a document will do it, as will a misread instruction or a misconfigured pipeline.​

I call this borrowed authority. Security engineers know it as the confused deputy problem, which is decades old. What agents change is volume and improvisation. They chain calls in sequences no engineer scripted, and software that writes software defaults to the flexible shared service because it is the fastest route to a passing test. Nobody schedules its removal.

​Where The Platforms Stand

​Each major data platform offers a way to enforce access controls closer to the user’s identity. Databricks explains in its documentation that when an app accesses resources through its own service principal, all users share that principal’s permissions, preventing the platform from automatically enforcing fine-grained policies based on individual user identities. With user authorization, Unity Catalog’s row filters and column masks can instead enforce the user’s existing permissions.

Who Is Accountable

​NIST’s AI Risk Management Framework assigns accountability to leadership: Executive leadership takes responsibility for risks associated with AI development and deployment.

Four requirements follow: