The AI agent inherits your credentials: the hidden risk in SMEs

The adoption of AI agents in enterprise environments is advancing rapidly, but we often overlook a critical aspect: the identity and permissions with which they operate. A recent article from The New Stack focuses on a common but dangerous practice: giving an AI agent an employee's personal credentials. The author, after handing over his Azure credentials to a coding agent, measured what it could actually do and discovered concerning results.

The experiment revealed that the agent could access two permissions in one production store and 107 in another. Furthermore, the environment where it could delete data from a secure database was the only one without auditing enabled. These findings are not mere anecdotes: they reflect an identity model that is rarely consciously designed.

Impersonation authentication: the token says it all

When an agent authenticates using a human's credentials, the resulting access token includes the user_impersonation scope. According to RFC 8693, this means the agent receives all the user's rights and is indistinguishable from them. In practice, the agent becomes an extension of the employee, with the same privileges and without its own identity to differentiate it.

The token also includes the mfa claim, indicating that each action of the agent carries the attestation that a human completed a second factor. This can give a false sense of security, since MFA was performed hours earlier for another task. Moreover, although the token has a lifespan of 84 minutes, the CLI renews it automatically, so an unattended process can continue operating indefinitely until the refresh token expires or the user account is disabled.

For an SME, this means that if an employee with high privileges connects an agent to their credentials, that agent will be able to do everything the employee can do, without additional control. And worse, the agent's actions will be logged under the employee's name, making attribution difficult.

Group-based authorization: the audit hole

The article describes how, when reviewing direct role assignments, only a reader role appeared in a non-production subscription. However, group membership revealed 34 active memberships and access to 7 subscriptions, including production ones. Groups grant access to data and live in the data plane, where control plane queries do not see them. A security reviewer who only looks at direct role assignments will get a biased view and a false sense of a small blast radius.

This pattern is common in organizations that manage permissions through Active Directory or Azure AD groups. For SMEs, it is common for IT teams to grant permissions to groups to simplify administration, but then not review what an agent inherits when it connects with a user account.

The conclusion is clear: group-based authorization controls can go unnoticed in traditional audits, and AI agents inherit all those permissions without anyone noticing.

The audit problem: no trace of the agent

Another concerning finding is that database sessions record the human's login name, the program name (sqlcmd), and the host, but there is no field indicating whether the query was executed by a person or an agent. This makes the actions of the agent and the human identical in the logs. As a consequence, differentiated policies cannot be applied: no rate limits, no approval steps, no different retention for automated actions.

Furthermore, if a query is questioned in the future, the human cannot prove that they did not execute it. The lack of traceability is both an operational and legal risk.

In the described environment, the only system without auditing was precisely where the agent could delete data from a secure database. This underscores the need to review the audit configuration in all systems, especially those with elevated permissions.

What does this imply for an SME?

SMEs often have small IT teams and prioritize agility over security. Giving human credentials to an agent is quick and requires no additional infrastructure, but it carries significant risks:

• Lack of attribution: it cannot be distinguished whether an action was performed by a human or an agent.
• Excessive permissions: the agent inherits all the user's permissions, which are often more than necessary.
• Complicated revocation: if the agent's access is revoked, the human's access is also revoked, which can affect their work.
• Insufficient auditing: logs do not reflect the agent's intervention, making incident investigation difficult.

Additionally, the complexity of group-based permissions makes it easy to overlook unwanted access.

Recommendations for IT teams

To mitigate these risks, at ForgeNEX we propose a series of practical measures:

1. Dedicated identities for agents: create specific service accounts for each agent, with minimal permissions and reviewed periodically. This allows clear attribution and easy revocation.
2. Review of inherited permissions: audit not only direct role assignments but also group memberships that grant access to data. Tools such as conditional access policies can help.
3. Enable auditing on all systems: ensure that all data stores, especially production ones, have auditing enabled and that logs include the origin of the action (human or agent).
4. Limit the scope of tokens: avoid the use of user_impersonation and opt for specific delegated permissions for the agent. If not possible, shorten token lifespans and avoid automatic renewal in unattended processes.
5. Monitoring and alerts: implement alerts when an agent performs unusual actions, such as deletions or access to sensitive data, even if the log does not initially distinguish it.

As we have seen in other articles, such as AI in the SOC: how much autonomy to cede without losing control?, the key is to balance autonomy with control. AI agents can bring great value, but they must operate under a well-defined identity model.

Conclusion

The practice of giving human credentials to AI agents is a shortcut that can be costly. SMEs must become aware that agents inherit not only permissions but also the identity and privileges of whoever lends them their credentials. Designing an identity strategy for agents, with dedicated accounts and adequate auditing, is essential to avoid unpleasant surprises. At ForgeNEX we can help implement these measures and review the configuration of your systems so that AI is a safe ally.

Source: The New Stack. Analysis and adaptation: ForgeNEX.