AI Agents Should Inherit User Permissions, Not Hold Their Own Credentials

Every new integration raises the same security question: what can it reach that a person couldn’t? For AI agents the answer depends on one design choice. Either the agent holds credentials of its own, or it acts with the permissions of the person who asked.

That choice decides how big the access surface becomes. A shared service account with broad scope creates a privileged identity that nobody reviews like a person, and it can reach data no single user was meant to see. Permission inheritance avoids that problem at its source.

This article explains why standing agent credentials are risky, how permission inheritance works in practice, and which questions to put to any agent platform during security review.

Executive Summary

AI agents should act as the requesting user. When an agent inherits a person’s roles and permissions, it can’t see or do more than that person, policy is evaluated on every request, and the audit trail attributes each action to a named individual. Agents with their own broad credentials do the opposite: they expand the access surface and break the link between an action and an accountable user. For CISOs and security architects, inheritance turns agent review into a question about the platform’s access model rather than about each agent’s code.

Key Takeaways

1. Standing agent credentials create a new privileged identity. A service account with broad scope can reach data no individual user was meant to access.
2. Inheritance keeps the access surface the same size. An agent that acts with the user’s roles and permissions can’t reach resources outside that authorisation.
3. Policy should be evaluated on every request. Attribute-based decisions that weigh classification, user attributes and context keep control with the platform instead of the agent.
4. Declared tool scope turns security review into document review. When an agent states what it can do before installation, reviewers assess a specification instead of auditing code.
5. Administrators need a central switch. Destructive tools stay off until they are enabled explicitly, and the exposed tool list can be restricted, which keeps agent behaviour inside what the organisation has approved.

Why Standing Agent Credentials Create Risk

Integration shortcuts tend to follow the same path. Someone creates a service account, grants it enough scope for the project to work and moves on. The account then lives for years, accumulating access nobody reviews against a person’s role.

A Privileged Identity Nobody Reviews

Users change roles, leave and lose access. A service account does none of that on its own. If an agent holds one, its reach reflects the day it was set up, not the current needs of the person asking.

Actions Without an Accountable User

When the agent acts as itself, the log shows the agent. It doesn’t show which person triggered the action or whether that person had any right to the data. For an investigator or an auditor, that’s a gap in the chain of accountability.

How Permission Inheritance Works for AI Agents

With inheritance, an AI operation carries the authenticated user’s roles and permissions. The platform evaluates attribute-based policy in real time for each request, using file classification, sensitivity labels, user attributes and context. If the user couldn’t open the file directly, the agent can’t open it either.

Declared Tool Scope

Each agent declares up front which tools it uses. Reviewers then compare that declaration with their requirements before installation. Tool calls are also checked against the scopes granted to the client, so an agent can only use the tools it was approved for.

Central Control for Administrators

Destructive tools such as move and delete are off by default and have to be enabled explicitly. Administrators can also restrict which named tools are registered for agents, and confirmation steps sit in front of write actions. Together these controls let a security team decide what agents may do before anyone installs one.

Questions to Put to Any Agent Platform

Ask whose permissions an agent runs with and whether any credential of its own exists. Ask where policy is evaluated, and whether security tokens or file data ever enter the model’s context without a user action. Ask how every call appears in the audit log and whether it reaches your SIEM. A platform that answers these precisely makes review fast. One that answers with a description of the assistant’s good behaviour hasn’t answered at all.

Why the Enforcement Point Matters

An assistant can be manipulated by a malicious document or prompt. Controls that depend on the assistant behaving well fail in that moment. Controls enforced at the connector, such as keeping tokens out of context and keeping transferred file data out of it unless the user reads a file in on purpose, still hold.

Enforcing Inheritance on the Kiteworks Data Control Plane

Posture tools describe where sensitive data lives and IAM decides who may sign in. Neither governs what an agent does once it acts for a user. The Kiteworks Data Control Plane applies identity, permissions and data-aware policy to that moment, and its audit log is tamper-proof and can feed your SIEM tooling. The Kiteworks Agent Marketplace is one way to see this model working, with agents that run as the requesting user inside Kiteworks.

It works alongside your IAM, DSPM and DLP tooling, which keep their roles. If you’d like to review the access model with your security architects, schedule a custom demo and we’ll go through the controls step by step.