Your Most Important Enterprise Users May Not Be Human
Integration users, service accounts, automation identities, and AI agents are becoming workload architecture.
This article is part of the Modernizing The Enterprise Platform series, which uses Salesforce as the evidence base for a broader discussion about enterprise architecture, AI, data, integration, identity, security, governance, DevOps, and operating models in mature enterprise platforms.
Most access governance conversations still begin with employees. That is understandable. Employees join, move roles, leave the organization, request access, receive approvals, and appear in familiar identity processes. The controls are imperfect in many organizations, but the mental model is well established: a human needs access to do a job, and that access should match the job.
The harder problem in mature enterprise platforms is that some of the most powerful users are not human.
Integration users, service accounts, automation identities, middleware credentials, batch users, connected app identities, and AI agents often sit behind critical business processes. They move data, create records, update statuses, synchronize systems, trigger downstream actions, and operate across boundaries that no individual employee could cross casually. In many environments, they are governed less carefully than employees because they do not fit the familiar lifecycle.
Salesforce has made this visible for years. A single integration user may have broad access because narrowing permissions felt risky. A service account may be shared across processes because no one wanted to create separate identities. A connected app may outlive the project that introduced it. A credential may be known by a vendor, an internal team, and an automation platform, with no clear owner responsible for rotation or decommissioning. The account is not a person, so it falls between the controls designed for people.
That gap creates real risk. Shared accounts destroy accountability because actions cannot be tied cleanly to an owner. Long-lived credentials create silent exposure because they continue working after everyone has stopped thinking about them. Broad permissions hide weak process design because the integration can access everything it might need. Teams may know what a service account can access, but not what breaks when it fails.
What I find more interesting is that non-human identities are not just security objects. They are workload architecture. Each one represents a business capability, a technical boundary, an operational dependency, and a failure mode. If an integration user fails, orders may stop synchronizing. If a certificate expires, a partner process may break. If an AI agent has excessive access, it may act on information it should only have been allowed to read under narrower conditions. If no one owns the identity, no one owns the continuity of the workload behind it.
That is why every non-human identity should have a defined business owner, a defined technical owner, a clear purpose, least-privilege access, a modern authentication method, credential or certificate rotation, monitoring and alerting, a failure-recovery process, and a decommissioning trigger. None of that is exotic. It is basic operational discipline. The problem is that many organizations never applied the discipline because the accounts were created to make a project work, not to create a long-lived architecture asset.
The ownership split matters. A technical owner may know how the credential works, how the integration is configured, and where the logs live. A business owner should know why the workload exists, what business process depends on it, how much downtime is tolerable, and whether the workload is still needed. Without both forms of ownership, the identity becomes an orphan with permissions.
AI agents make this issue more urgent because they can act across several systems and because the language used around them can blur accountability. An agent may read from Salesforce, call an external system, summarize a customer issue, recommend an action, and update a case. Each step depends on access, authorization, policy boundaries, observability, and error handling. Treating that agent as a clever interface misses the point. It is a non-human actor participating in enterprise work.
This does not mean every agent or integration needs unrestricted autonomy. In fact, the opposite is true. The more action a non-human identity can take, the more carefully its authority must be bounded. It should have access to what it needs, not to everything that makes implementation convenient. It should be monitored as a workload, not forgotten as a setup artifact. It should have an owner who can answer what it is allowed to do and what should happen when it behaves unexpectedly.
To be clear, I am not arguing that non-human identities are inherently dangerous. They are essential to modern enterprise architecture. The business cannot operate without integrations, automation, and increasingly AI-supported workflows. What I am arguing is that their importance has outgrown the casual governance many organizations still apply to them.
A mature identity program has to include the identities that do not appear in the employee directory. A mature Salesforce architecture has to treat integration users and automation identities as first-class design elements. A mature AI architecture has to define agent authority before agent behaviour becomes production behaviour.
The enterprise users that matter most may not attend meetings, submit access requests, or appear on an org chart. They may still have more operational power than most people in the company. Architecture needs to treat them accordingly.
Continue The Series
- 1. Salesforce Is Still Part Of The Conversation. It Is No Longer The Boundary.
- 2. The Hardest Salesforce Work Starts After Go-Live
- 3. Enterprise Platforms Do Not Become Complex Because They Are Old
- 4. Technical Debt Is Not Old Code. It Is Unmanaged Decisions.
- 5. Enterprise Platforms Fail When Responsibility Exceeds Authority
- 6. DevOps Is An Operating Control, Not A Deployment Tool
- 7. Your Most Important Enterprise Users May Not Be Human
- 8. AI Agents Do Not Fix Weak Enterprise Architecture. They Expose It.
- 9. Enterprise AI Should Not Be Deterministic Everywhere
- 10. An Architecture Recommendation Is Incomplete Until It Explains What Was Rejected
- 11. Modernization Is The Art Of Changing The System Without Stopping The Business