A finance team introduces an AI assistant to investigate invoices that do not match purchase orders. It can read supplier records, invoices, and an email account. To get the pilot moving, the team gives the whole workflow one service account.
The pilot works. Its developer later moves to another role. Finance assumes Technology manages the account; Technology assumes Finance still owns it. Six months later, the same permissions support a much larger workflow.
Then a supplier’s payment details change without the normal approval. The audit log identifies the shared service account. It cannot show who initiated the change, which agent chose the tool, why the action was permitted, or why the account still held that access.
The organization knows which account acted. It cannot establish who authorized the action or whether the software was entitled to take it.
This is a composite case, but the operating problem is familiar. Software now receives identities and permissions that were once associated mainly with employees. The credentials may be well protected while the authority behind them has no clear owner, no current purpose and no agreed ending.
The issue in plain English
A machine identity is the digital identity used by software when it talks to another system. It may be a service account, workload identity, certificate, or token-backed account. Think of it as an employee badge issued to software.
Security teams rightly protect the badge. But a secure key can still open the wrong door. Changing a password or rotating a token reduces the chance of theft; it does not reduce the authority attached to the identity.
The practical test is simple. Whenever software can move money, alter important records or reach sensitive data, the organization should be able to answer four questions in ordinary language.
1. Who owns this identity?
Employee access usually begins with a job and ends when the employee leaves or changes roles. Software identities rarely have such a natural ending. They can sit between a business process, an application team, a platform team, and a vendor. Each group manages one part, while nobody accepts responsibility for the whole permission chain.
Technology may maintain the identity, but maintenance is not ownership. The business owner should decide whether the purpose still exists and accept the operational consequence of keeping, narrowing or suspending the access.
The record should name the accountable role, the person currently holding it, a deputy, and the technical custodian. A team name alone is insufficient when an urgent decision must be made at 2 a.m.
2. What is it allowed to do?
The answer should describe a job, not merely a list of permissions. For the invoice assistant, the job might be: investigate invoice mismatches and prepare evidence for Finance. That purpose justifies reading invoices, purchase orders, and supplier records. It does not justify changing bank details or releasing a payment.
AI agents make this boundary harder to see. One request can cause an agent to choose several tools and take actions that no person specified step by step. Permission must therefore be enforced outside the model. The model may propose an action; it must not decide the limit of its own authority.
When an agent acts for a signed-in employee, the action should be allowed only where four conditions meet: the employee has permission, the agent is approved for the task, the tool is allowed to operate, and the target system accepts the transaction. A background process should use a separate identity with narrower authority.
High-impact actions need further limits. A valid identity should not be enough to move money, change master data, or send sensitive information. The system that gives the agent access to a tool, or the target system itself, can enforce transaction limits, check destinations and require fresh approval when the purpose or value changes.
3. Can we explain what happened?
A conventional audit log may show that a service account changed a record. That is useful, but it does not establish why the change occurred or whether the authority was legitimate.
For a consequential action, the evidence should connect the initiating person or event, the agent and configuration version, the policy decision, the tool used, any approval, the affected resource, and the result. This establishes what authority was exercised and why the system allowed it. It does not pretend to reveal every internal step in the model’s reasoning.
Give the transaction one case number that appears in every relevant record. Without it, an investigation becomes a search across separate logs whose clocks, names, and retention periods may not agree.
Evidence also needs restraint. Keep what is necessary to explain and investigate the action, protect log integrity, and apply privacy and retention rules. More logging is not automatically better if nobody can find the relevant decision or sensitive data is retained without purpose.
4. Can we stop it safely?
An identity is not properly governed until the organization knows how to remove its authority and what will happen next. Emergency shutdown may contain an incident. It may also stop invoicing, customer service or a critical overnight process.
The owner and custodian should test the stop route before an incident. They should know how to disable the identity, invalidate its keys or tokens, remove one permission without disabling everything, and move essential work to a safe manual or restricted fallback.
This is where ownership becomes practical. The person who can press the stop button may not be authorized to accept the business consequence. Both roles must be known before pressure arrives.
A completed finance example
The invoice assistant does not need a person to approve every search or comparison. It may gather evidence and propose a response. Controls outside the model prevent it from changing supplier banking details, releasing payment, or sending external email.
- A finance analyst opens case AP-1842 and asks the assistant to investigate a mismatch.
- The policy service confirms that the analyst may inspect this supplier and that the agent may use read-only finance tools.
- The assistant compares the invoice, purchase order and supplier record, then proposes a case note.
- A requested bank-detail change is blocked and routed into the existing two-person approval process.
- The case record links the request, policy result, tool calls, blocked action, human approvals and outcome.
A bank-detail change enters the existing two-person approval process. One person requests the change, and another independently approves it. The supplier is verified through contact details already held in an independently maintained record or executed contract, never through details supplied in the change request.
| Question | Invoice-assistant answer |
| Purpose | Investigate invoice mismatches and prepare evidence for Finance. |
| Owner | Head of Accounts Payable, with a named deputy. Business Applications remains the technical custodian. |
| Allowed | Read invoice, purchase-order and supplier records; draft an internal case note. |
| Withheld | Change bank details, release payment or send external email. |
| Evidence | Requesting user, case ID, tool used, records accessed, policy result and proposed action. |
| Stop route | Disable the workload identity and return invoice review to the documented manual process. |
What these controls do not solve
Identity controls cannot make a poor business rule sensible, detect every malicious document or guarantee that a model’s recommendation is correct. They constrain what software may reach and do, preserve evidence and make intervention possible. High-impact workflows still need sound process design, data checks and human judgement at the point where consequences change.
This distinction matters during incidents. A team may discover prompt injection or faulty reasoning and still contain the effect if the agent cannot change bank details, export a customer list or approve its own exception. Identity is one control layer, not a complete AI safety system.
The control baseline
The four questions provide the management spine. The following checks make them operational.
Find and classify
Locate software identities across cloud platforms, SaaS products, code repositories, automation tools and on-premises systems. Classify them by consequence. Read-only access can still be critical when it exposes sensitive data, secrets or a route into other systems.
Record purpose and authority
Give each identity with higher-impact access a short job record: purpose, owner, custodian, permitted resources and actions, delegation method, review date, evidence source and stop route. Record credential metadata and its approved vault reference, never the secret itself.
Prefer bounded access
Use platform-managed identities and short-lived credentials where the platform supports them. Separate read from write access and different purposes from one another. Short credential life reduces exposure if a credential is stolen; it does not correct excessive permission.
Watch use and rehearse failure.
Monitor activity outside the expected system, time, volume, or action pattern. Repeated denials may indicate misuse, attack, or a poor permission design. Investigate the cause instead of automatically broadening access. Test revocation and the fallback process.
Do we need another identity product?
Often, no. Many organizations already have controls that can discover identities, protect credentials, restrict permissions and review access. The missing part is usually coverage or ownership. Service accounts may sit outside existing reviews, cloud evidence may not reach the central team, or an overprivileged application may never have been redesigned.
Nor does every short-lived software instance need a separate committee record. Govern at the level where purpose, permission, risk, or evidence changes. Many temporary instances doing the same tightly constrained job can share one control pattern, provided each request remains attributable.
Legacy and vendor-managed systems deserve honest treatment. Some still depend on shared accounts or weak logs, and revocation may interrupt an essential service. A temporary exception needs an owner, an expiry, a tested fallback and a recorded acceptance of the remaining risk.
What a CIO can ask next week
Choose one AI-enabled workflow that can change data or trigger an external action. Ask the team to trace one completed transaction from the original request to the final system effect.
For every identity used along the way, record its owner, purpose, permissions, credential type, review date, and stop route. Then ask:
Could any identity do more than this transaction required?
Could we explain who or what caused the action and why it was allowed?
Could we remove the authority today without losing an essential service?
The answers will show whether the first repair belongs in technology, process ownership or both. A valid service account shows that a recognized identity acted. It does not establish that the action served an approved purpose, that someone still owns the risk or that the authority can be withdrawn safely.
When software can cause a material business effect, a CIO should be able to name the machine that acted, the purpose that justified its access, the person accountable for that authority and the tested way to stop it. When one answer is missing, the organization has granted power that it cannot yet fully explain or reliably withdraw.
Editorial note. The finance and customer-workflow examples are composites created to explain common operating patterns. No organization or incident is being described.
Selected sources for editorial review
- NIST SP 800-207A: A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments, September 2023
- OWASP Foundation, Non-Human Identities Top 10 2025
- Microsoft Learn, Identity for AI agents
- Microsoft Learn, Access patterns and controls for AI agents
- Amazon Web Services, Security best practices in IAM
- Google Cloud, Best practices for using service accounts securely
Explore more articles by Mani Padisetti.
Human-in-the-Loop Is Not Enough: Where Is the Human Authority Line in AI-Supported Decisions?
Why Clean CRM Data is the Key to Unlocking AI’s Potential
My journey as the COO, vCIO, and Co-Founder of Digital Armor Corporation; Co-Founder and CEO of Emerging Tech Armory; and Curator, Almost Magic Tech Lab reflects my extensive experience and unwavering dedication to helping medium-sized businesses leverage technology for growth and success. With over two decades of founding and running my own company, I have established myself as a trusted expert in empowering SMBs to enhance productivity, scale effectively, and gain a competitive advantage in their respective industries.
I often refer to myself as the “Growth Catalyst for Mid-Sized Businesses” because I understand the unique challenges these enterprises face, such as limited budgets. I deliver tailored solutions that address their specific goals and constraints.
My secret ingredient to effective leadership is finding joy in being a catalyst for others’ success. I firmly believe in acting in the best interest of my clients, genuinely caring for their businesses as if they were my own. This client-centric approach forms the foundation of my leadership philosophy, driving me to go above and beyond to ensure my clients’ satisfaction and prosperity.
