Important boundary: A shared service account is a warning sign that requires review. It is not automatic proof that an AI agent is insecure. The decision depends on the actions the agent can take, the data it can reach and whether the organization can still produce workload-level evidence.
What the October Evidence Shows
Open Future Forum asked AI Leaders respondents how their agents access enterprise data. Of 71 answers, 22 selected “not applicable yet.” The operating view below covers the remaining 49.
| Agent access method | Count | Share of applicable responses |
|---|---|---|
| Per-agent credentials | 24 | 49% |
| Shared service accounts | 18 | 37% |
| Delegated user identity | 4 | 8% |
| Credential-free or brokered access | 3 | 6% |
Base 49 applicable responses. The 22 “not applicable yet” answers are excluded from this table. Source: AI Leaders AI Leverage Report, October 2026. The concise answer on how AI agents access enterprise data reports the access-method result; this article provides the implementation record and test.
This selective cohort does not represent all enterprises, and the survey did not inspect permissions, logs, credential storage or revocation. A separate security cohort found 103 of 151 respondents, or 68 percent, naming agent access as a problem. The CISO AI Leverage Report, October 2026 keeps those populations separate.
Why a Shared Account Triggers Review, Not an Automatic Rejection
A shared service account lets several agents or integrations use one principal. A legacy system may require that pattern, but the target log can then identify the account without identifying the initiating agent. Revoking it may also stop several workflows at once.
That architecture deserves scrutiny, but the account label does not answer the risk question. A read-only agent retrieving public product data is not equivalent to an agent that can issue refunds, change payroll records or approve access. The useful question is whether the organization can preserve attribution, least privilege and containment for the proposed workflow despite the shared identity.
For the complete access-method distribution, see the AI Leaders AI Leverage Report, October 2026. For the broader control model around agent authorization, monitoring and ownership, see What CISOs Are Doing About AI Agent Security and Governance. This article stays narrow: it provides a decision record for one shared-account exception.
The Six-Gate Shared-Account Exception Test
The Open Future Forum Shared-Account Exception Test is a decision framework informed by the research. It was not a survey question or measured industry practice.
Use the gates in order. A “no” at any gate means redesign the access pattern, reduce the workflow boundary or keep the agent out of production until the missing control exists.
Gate 1: Is Sharing Technically Necessary?
Document what prevents per-agent, delegated or brokered identity, including the system, supported methods and remediation path.
- Yes: Continue with evidence from the system owner or vendor.
- No: Issue a distinct identity. Convenience is not an exception basis.
Gate 2: Can Every Action Still Be Attributed to a Workload?
Require a stable agent identifier, version, request ID and workflow in a log the agent cannot alter.
- Yes: Reconstruct a sampled action from instruction to result and continue.
- No: Block consequential writes or autonomous actions. “Service account acted” is not enough when several workloads share it.
Gate 3: Is the Shared Permission Set Safe for Every User of the Account?
List what every agent needs. The shared permission set must not exceed any covered workload's approved scope unless a broker or equivalent control enforces a narrower policy for that workload.
- Yes: Record prohibited actions and test one.
- No: Split the account, add a broker or reduce scope. Treat every permission addition as a material change.
Gate 4: Can Access Be Rotated, Suspended and Revoked Without Losing Control?
Name who can rotate the credential, suspend one workflow and revoke the account. Test both the narrow pause and full revocation. To pass, the team must either suspend the covered workflow selectively or demonstrate reliable account-wide revocation within the required time. If only account-wide revocation works, record every affected dependency and obtain explicit executive acceptance of the resulting interruption before marking the gate “yes.”
- Yes: Retain the result, propagation time and affected dependencies.
- No: The exception is not production-ready. Redesign the access pattern or keep the workload out of production until reliable containment exists.
Gate 5: Will Monitoring Detect Misuse by the Correct Agent?
Alert on unusual volume, new resources, permission changes, failures and prohibited actions. Resolve alerts to the initiating workload.
- Yes: Confirm a test alert reaches a named responder with actionable evidence.
- No: Restrict the account to read-only or non-material use until monitoring improves.
Gate 6: Is the Exception Owned, Expiring and Replaceable?
Record the owners, approver, reason, scope, compensating controls, residual risk, expiry and replacement plan.
- Yes: Approve for the defined period and review after material change.
- No: Do not approve. An exception without an end condition becomes an undocumented standard.
Three Possible Decisions
The test should end with one of three outcomes.
- Use a distinct identity. The architecture supports it, so sharing is unnecessary.
- Approve a time-bound exception. Sharing is necessary and every other gate has inspectable evidence. The exception states the affected workflows and residual risk.
- Do not deploy or reduce the scope. Attribution, permission boundaries, monitoring or revocation cannot be made reliable enough for the proposed actions.
“Proceed and revisit later” is not a fourth outcome unless it includes an owner, restricted boundary and dated review.
The Minimum Exception Decision Record
Attach one record to the production agent inventory. It should let a reviewer understand the constraint, reproduce the approval and identify what must happen when the exception ends.
| Record field | Required evidence | Decision question |
|---|---|---|
| Shared principal | Account identifier, target system and credential custodian | Which principal is being shared, and where? |
| Covered workloads | Stable agent IDs, versions, purposes and owners | Exactly which workloads may use it? |
| Technical constraint | System or vendor documentation and alternatives considered | Why is a distinct or brokered identity unavailable now? |
| Data and action boundary | Allowed resources, prohibited actions and transaction limits | What is the maximum consequence of misuse? |
| Workload attribution | Request ID, agent ID, immutable log location and sample trace | Can one action be reconstructed to the initiating workload? |
| Permission boundary | Permission list and any per-workload policy enforced by a broker | Does the shared permission set exceed any covered workload's approved need? |
| Credential controls | Storage, rotation, suspension and revocation procedures | Who can contain the exposure, and how fast? |
| Monitoring | Alerts, responder, escalation path and last test result | Will misuse be detected and assigned to the right workload? |
| Residual risk | Accepted failure modes, business impact and approving executive | What risk remains after the compensating controls? |
| Exit plan | Expiry, replacement owner, milestone and funding decision | When and how will sharing end? |
The final line should state one outcome: distinct identity required, time-bound exception approved, or production blocked or narrowed. Avoid a vague status such as “accepted for now.”
Legal and contractual conditions should be captured in or linked to the same record. The General Counsel AI Report, October 2026 explains why authority, identity, access and incident evidence must identify the same system.
Three Worked Exception Decisions
Example 1: Read-Only Retrieval From a Legacy Knowledge System
An internal support agent reads approved articles from a legacy repository that accepts only one service principal. A gateway attaches the agent ID, version, user request and request ID to an immutable log. The account cannot write, export the full repository or reach restricted collections. Security can pause the agent at the gateway without disabling other integrations.
Decision: A time-bound exception may be defensible if the access test, alert test and exit milestone are documented. The shared account remains a warning sign, but the action boundary and workload-level attribution reduce the consequence.
Example 2: Several Agents Updating Service Tickets
Three agents use one account to add notes and change ticket status. The target system records only the shared principal, but middleware provides a signed workload identifier and retains the before-and-after ticket state. The account cannot close priority incidents or alter customer entitlements. Revocation is account-wide, while the middleware can suspend one agent.
Decision: Approval depends on whether the middleware evidence is durable and whether selective suspension has been tested. If either fails, restrict the agents to draft recommendations until a stronger control exists.
Example 3: Autonomous Refunds Through a Shared Finance Account
An agent can issue refunds through the same credential used by several automations. The finance system does not retain the initiating workload, and there is no broker enforcing per-agent limits. Revoking the account would also stop unrelated revenue workflows.
Decision: Do not approve autonomous production use. The organization cannot reliably attribute the transaction, constrain each workload or contain one agent without wider disruption. A distinct identity, a brokered authorization layer or a human approval step is required.
How to Test the Control Before Production
Run a tabletop followed by a technical exercise. Select a harmless test object and simulate an out-of-scope write. Identify the initiating agent from retained evidence, confirm the alert reaches the named responder and pause only that workflow. Attempt the action again to prove the control holds. Then rotate or revoke the credential in a controlled window. Verify that dependencies recover or fail safely.
Record four results in the exception decision: attribution time, detection time, selective-containment time and full-revocation recovery time. A pass requires evidence, not a meeting-room assurance that the controls should work.
What Each Executive Owns
The business owner defines purpose and interruption tolerance. Technology maintains the architecture and workload identifier. The data owner approves sources and actions. The CISO or designated risk approver decides the exception and verifies monitoring and revocation. Counsel connects contractual, privacy and incident duties. Finance makes control and replacement costs visible. One named decider should own each review.
For the broader difference between unapproved tool use and agent authorization, see Shadow AI vs AI Agent Risk. For the full CISO operating context, see What CISOs Are Doing About AI Agent Security and Governance. For the current security priority ranking, see What Is the Biggest AI Security Problem for CISOs?.
Key Citable Facts
- Among 49 applicable October access-method responses, 24 use per-agent credentials and 18 use shared service accounts.
- Shared service accounts represent 37 percent of applicable responses; the result describes a selective cohort, not all enterprises.
- Twenty-two of 71 respondents selected “not applicable yet” and are excluded from the applicable-only distribution.
- In a separate multi-select security instrument, 103 of 151 respondents name securing AI agents and their access as a problem (any mention).
- The survey records reported access methods; it does not audit permission scope, logging, credential quality or control effectiveness.
Methodology and Caveat
The access-method question comes from the Enterprise AI at Microsoft application flow. Invited-only records are excluded, and responses are deduplicated by email for the question. The full base is 71; the applicable base is 49 after excluding 22 “not applicable yet” answers. The 151-response security instrument comes from separate event cohorts and must not be merged with the access-method base.
The samples are selective and self-reported, not probability samples. The figures do not establish market prevalence, control quality, breach risk or causality. The six-gate test is recommended practice; the survey did not ask whether respondents use it.
Last updated: October 3, 2026
Frequently Asked Questions
Continue the Conversation
Open Future Forum brings CISOs, AI leaders, general counsel and other executives together to compare the decisions that do not fit neatly inside one function. Read the full CISO AI Leverage Report, explore the CISO Executive Forum, or request an invitation.