"We want to delegate invoice processing and data aggregation to AI." We hear this increasingly from companies exploring workflow automation. The direction is sound: delegating tasks that don't require human effort to AI agents genuinely frees up time. However, right before taking that step, you must pause and resolve a critical question: how will you grant that AI the "keys" to your internal systems and cloud services—namely, login credentials and access permissions?
Companies rushing forward while leaving this ambiguous are already running into serious incidents. A survey published in June 2026 (targeting companies with over 100 employees) revealed that 54% had already experienced a security incident or near-miss involving AI agents, and 69% reused the same credentials across multiple agents. While this might sound like a problem limited to large enterprises, the architecture of these incidents does not depend on company size. In fact, SMBs lacking dedicated IT teams are even more prone to handing over keys impulsively. This article explains the governance controls buyers must define before commissioning AI automation.
Why Credential Handling Directly Causes Incidents
The core of the problem is credential reuse. When multiple agents share the same key, a compromise or malfunction in one agent causes the damage to cascade across the entire system. It is the equivalent of distributing master keys that open every door in the building.
Moreover, unlike humans, AI agents bypass safeguards designed around human speed. At one three-person company, static access keys were stolen and used to run AI API calls, resulting in approximately $14,000 in cloud charges billed in a single day. In another instance, an autonomous agent provisioned roughly $6,500 worth of excessive infrastructure on its own within 24 hours. Because cloud billing data typically appears about a day after operations occur, relying on a strategy of "noticing when the bill arrives" means the loop-driven agent has already racked up a full day of costs by the time you realize what happened.
In short, granting keys to AI agents must be designed fundamentally differently from granting permissions to human employees, in terms of both security and financial liability. The boundary of who accepts liability for "AI automation capabilities" is also addressed in our article on division of responsibility in AI automation.
Three Principles to Establish Before Delegating Tasks
The aforementioned survey showed that only about one-third of companies assign unique, narrowly scoped permissions (scoped identities) to each agent, and only 30% isolate their highest-risk agents. Looked at another way, mastering these basics immediately puts you ahead of the majority in security. As a buyer or project sponsor, you must establish the following three points:
| Principle | Specific Decision | Incidents Prevented |
|---|---|---|
| Never reuse keys | Issue a distinct identity for each agent | A single compromise cascading across the entire environment |
| Enforce least privilege | Grant access only to the scope required for that task | Unintended operations and unauthorized data exfiltration |
| Log activities and set hard limits | Configure audit logs alongside cost and rate caps | Stopping runaways at the moment of execution |
The third principle is particularly effective against runaway costs. Rather than noticing via billing alerts, implement mechanisms that detect and halt actions at the operational level—such as spinning up infrastructure or making massive API calls. Having this control can reduce worst-case billing amounts by an entire order of magnitude.
Securing Agreement on "Who Governs What" at Procurement
When contracting out AI agent development or automation, securing agreement on these controls as procurement requirements from the very start is essential. Attempting to retrofit permission architecture after functional code is written is like trying to replace a building's foundation after the house is built.
Specifically, ask these questions during procurement: "Is the architecture designed to grant separate, scoped permissions to each agent?" "Is it predicated on never reusing credentials?" "Who manages operational logs and cost limits, and how?" If the vendor can clearly answer these three questions, they understand how to build with proper governance. Technical details on access management when connecting AI agents to internal systems are detailed in our article on MCP authorization, and setting up company-wide rules for AI usage is covered in our article on AI usage guidelines for SMBs.
Case Study: The Company That Started Safely with "One Task, One Dedicated Key"
A mail-order company with about thirty employees (kept anonymous) approached us wanting to "delegate inventory aggregation and purchase order drafting to AI." Their initial proposal was simply to give the agent the administrative login credentials that their staff used daily. This is a textbook dangerous entry point.
Instead, we narrowed the delegated task strictly to "inventory aggregation" and issued a newly created, dedicated credential with read-only permissions limited to that specific operation. For writing data and finalizing purchase orders, the AI created drafts while requiring human approval, intentionally constraining the key's reach. Furthermore, alerts were configured to trigger if call volumes exceeded normal thresholds. What made this effective wasn't complex engineering: it was avoiding handing over everyday credentials in favor of creating a dedicated key for one specific task, and retaining human approval for finalizing operations. These two steps allowed them to begin automation safely in an environment where incidents simply could not occur. For password protection fundamentals, our article on account takeover prevention is also a helpful resource.
Start by Restricting Handed-Over Keys to a Single Scope
Automation powered by AI agents will be a powerful asset for SMBs going forward. However, making mistakes in how keys are handed over turns a tool meant to save time into an entryway for data breaches and runaway billing. The fact that 54% have experienced incidents is not fearmongering; it reflects the reality that most stumble right at the entrance. If you are getting started, begin by narrowing down to a single task and provisioning a dedicated, tightly scoped key specifically for that job.
If you want to adopt automation but feel uneasy about credential management, need to verify whether a contractor's permission model is sound, or want mechanisms to prevent runaway actions, please reach out via GleamHub's Development, AI, and Automation Consultation Desk. We will guide you from selecting a safe first task to tailoring governance for your organization.
