ISO 27001
Least Privilege
Identity Management
AI Agents
From Service Accounts to Agent Identities: What Evidence Proves Least Privilege?
Learn how ISO 27001 internal auditors can prove least privilege across service accounts, workload identities, service principals, bots, and AI agents.
Least Privilege Is Easy to Claim
“Access follows least privilege.”
It is one of the most common statements in security policies.
However, the statement itself proves very little during an internal audit.
The auditor needs evidence.
That becomes harder when access belongs to machines instead of people.
Run applications.
Connect cloud services.
Call APIs.
Execute tasks.
Read data, use tools, and take actions.
So, how can an organization prove that these identities only have the access they need?
That is the real least privilege audit question.
Quick Answer
What Evidence Proves Least Privilege?
An access list alone does not prove least privilege.
Internal audit should be able to connect the full evidence chain.
Business Purpose → Identity → Required Access → Actual Access → Approval → Review → Activity
For service accounts, workload identities, and AI agents, auditors should check:
- Who owns the identity.
- Why it exists.
- What resources it can access.
- Which actions it can perform.
- Who approved the access.
- Whether broader permissions were rejected.
- When access was last reviewed.
- Whether actual activity matches the approved purpose.
- Whether access can be removed quickly.
Bottom line: if these links cannot be shown, least privilege may exist in policy but not in practice.
Least Privilege Has Changed
In the past, access reviews often focused on employees.
Does Jane still need Finance access?
Should John still be an administrator?
Those questions still matter.
However, the modern identity environment is much larger.
Microsoft defines workload identities as identities assigned to software workloads.
These workloads can include applications, services, scripts, and containers.
The identity allows the workload to authenticate and access resources.
AI agents now add another identity type.
Microsoft’s Agent ID model gives AI agents distinct identities for access control and auditability.
Practical rule: an ISO 27001 access review should include every identity that can reach important systems or information.
1. Evidence of Business Purpose
Start with a simple question:
Why does this identity exist?
Every important service account, workload identity, or AI agent should have a documented purpose.
Example
Service account SA-FIN-REPORT retrieves approved financial data each night. It then places the report in the reporting repository.
That statement gives the auditor something to test.
If the account can also delete records or modify users, its permissions do not match its purpose.
Microsoft recommends mapping service accounts to a specific service, application, or script. It also recommends assigning an accountable owner.
Good Evidence
- Identity register.
- Business purpose.
- Application or workflow name.
- System owner.
- Technical owner.
- Data owner.
- Risk classification.
Weak evidence: “Needed by IT.”
2. Evidence of Required Access
Next, ask:
What access does the workload actually require?
Define this before comparing it with the real permissions.
For example, an AI agent may need to:
However, it may not need to:
That distinction matters.
Least privilege means giving an identity only the access required for its approved task.
Audit Evidence
- Access requirements.
- Role design.
- API scope requirements.
- Architecture diagrams.
- Data-flow diagrams.
- Tool inventories.
Then compare the requirement with reality.
3. Evidence of Actual Permissions
Policies show what should happen.
Configuration shows what is happening.
Therefore, internal audit should inspect the real permissions.
Then ask:
Does every permission support the documented purpose?
If not, challenge it.
Microsoft recommends giving service accounts only the permissions needed for their tasks.
The Best Audit Test
| Evidence | Example |
|---|---|
| Business Purpose | Read customer tickets. |
| Required Access | Read Support Queue A. |
| Actual Access | Read and write across all support queues. |
| Audit Result | Excessive access. |
This makes least privilege measurable.
4. Evidence of Access Approval
Access should not appear without a decision.
Ask:
Who approved these permissions?
The organization should be able to show:
- Access request.
- Requested role.
- Business justification.
- Approver.
- Approval date.
- Risk or security review where needed.
For sensitive access, the approver should understand what the permission allows.
Approving an application called “Customer Support Bot” is not enough.
The approver should understand whether the bot can:
Auditors should review the actual permission, not only the application name.
5. Evidence of Scope
Least privilege is not only about what an identity can do.
It is also about where it can do it.
For example, an automation account may need deployment rights.
But does it need those rights across:
Likewise, an AI agent may need SharePoint access.
But does it need:
Microsoft describes least privilege in terms of specific permissions, scope, and duration.
Can You Prove Your Machine Identities Follow Least Privilege?
Canadian Cyber can review service accounts, workload identities, AI agents, API scopes, privileged access, approval evidence, and access-review records.
The goal is simple: connect business need to real technical access before your next ISO 27001 audit.
6. Evidence of Regular Access Reviews
Access that was correct two years ago may be excessive today.
Applications change.
Projects end.
Systems migrate.
Owners leave.
AI agents gain new tools.
Therefore, machine identities need regular access reviews too.
Review Evidence Should Show
- Identity reviewed.
- Current owner.
- Current purpose.
- Current permissions.
- Review date.
- Reviewer.
- Decision.
- Access removed where appropriate.
A review that only says “Approved” is weak.
A stronger review compares current permissions with current business needs.
Microsoft also recommends defined review periods and lifecycle processes for service accounts.
7. Evidence From Actual Activity
This is where a least privilege audit becomes much stronger.
Do not only ask:
What can this identity access?
Also ask:
What does this identity actually access?
Suppose a service principal has access to 25 resources.
However, the logs show activity in only three resources during the last six months.
That creates a clear audit question:
Activity evidence may include:
Unused access is not automatically unnecessary.
However, it should be investigated.
8. Evidence of Restricted Privilege
Some machine identities need elevated access.
That does not remove the need for least privilege.
It makes least privilege even more important.
For privileged identities, ask:
- Why is privileged access required?
- Can a narrower role work?
- Can the scope be reduced?
- Can the duration be reduced?
- Can the task be split?
- Is privileged activity monitored?
Microsoft advises against putting service accounts in privileged groups unless that access is clearly required.
It also recommends granular permissions instead of broad administrative rights.
Red Flag
“The application would not work otherwise.”
That may be true.
However, it still needs evidence.
9. Agent Identities Need Different Questions
AI agents make least privilege more complex.
Traditional applications are usually predictable.
They perform predefined actions.
AI agents may behave differently.
They can make decisions dynamically and use several tools to complete a task.
Microsoft now distinguishes agent identities from traditional service principals.
Dedicated agent identities can improve audit records, sponsorship, lifecycle control, and authorization.
For Every AI Agent, Ask
- Does it have a unique identity?
- Who sponsors or owns it?
- What data can it access?
- Which tools can it call?
- Can it act autonomously?
- Can it act on behalf of a user?
- Can it perform write actions?
- Are sensitive actions approved?
- Are its actions logged separately?
- Can its authority be revoked?
NIST is also examining software and AI agent identity.
Its 2026 work covers identification, authentication, authorization, delegation, auditing, and least privilege.
That makes AI agent authorization an important emerging audit area.
10. Evidence of Time-Limited Access
Least privilege should also consider time.
An identity may need elevated access for:
That does not mean the access should remain forever.
Where possible, use:
- Expiration.
- Temporary permissions.
- Short-lived tokens.
- Time-limited roles.
- Automated removal.
- Defined end dates.
Ask:
When should this access stop?
If the answer is “when someone remembers,” the control is weak.
What Does Strong Least Privilege Evidence Look Like?
Strong evidence creates a clear chain.
Identity
↓
Named Owner
↓
Business Purpose
↓
Required Permission
↓
Approved Permission
↓
Actual Configuration
↓
Activity Logs
↓
Periodic Review
↓
Removal When No Longer Required
That is far stronger than a policy statement.
“All accounts shall follow least privilege.”
The policy sets the expectation.
The evidence proves the control.
ISO 27001 Controls to Consider
Several ISO/IEC 27001:2022 controls may support a least privilege audit.
| ISO 27001 Control | Audit Focus |
|---|---|
| A.5.15 Access Control | Are access rules defined? |
| A.5.16 Identity Management | Are identities governed through their lifecycle? |
| A.5.17 Authentication Information | Are machine credentials protected? |
| A.5.18 Access Rights | Are permissions approved and reviewed? |
| A.8.2 Privileged Access Rights | Is elevated access restricted? |
| A.8.3 Information Access Restriction | Is access limited to required information? |
| A.8.15 Logging | Are identity actions recorded? |
| A.8.16 Monitoring Activities | Is unusual behaviour detected? |
The exact controls depend on the organization’s systems, risks, scope, and Statement of Applicability.
Common Least Privilege Audit Findings
Internal auditors should watch for these patterns.
The identity exists, but nobody is accountable for it.
Read-only tasks have write or administrative access.
An identity needs one system but can access many.
Permissions remain after a project or integration changes.
Employees are reviewed regularly, but service accounts are not.
Several applications use the same account.
Agents can access sensitive information and use high-impact tools without clear restrictions.
Permissions are reviewed without checking whether they are actually used.
Short-term permissions were never removed.
Quick Least Privilege Audit Checklist
Before closing the audit, confirm:
- Machine identities are inventoried.
- Every important identity has an owner.
- Business purpose is documented.
- Required access is defined.
- Actual permissions match the requirement.
- Permission scope is limited.
- Privileged access has stronger justification.
- Access approvals are retained.
- Reviews happen regularly.
- Actual activity is considered during reviews.
- Unused access is investigated.
- Temporary access has an end date.
- AI agent identities are included.
- AI tools and actions are reviewed.
- Important identity activity is logged.
- Access can be revoked quickly.
Centralize Least Privilege Evidence in SharePoint
Least privilege evidence often sits across many teams.
IT may own the identity inventory.
Security may hold activity logs.
Application owners may hold the business justification.
Compliance teams may hold the audit findings and review evidence.
Canadian Cyber’s ISMS SharePoint Solution can help centralize:
Explore Canadian Cyber’s ISMS SharePoint Solution
Frequently Asked Questions
What evidence proves least privilege?
Strong evidence connects the identity’s business purpose with required permissions, approved access, actual configuration, activity, and periodic review.
Is an access review enough to prove least privilege?
Not by itself.
A stronger review compares actual permissions with current business needs and activity.
Do service accounts need access reviews?
Yes.
Service accounts can keep significant permissions for long periods. Their access should be reviewed based on risk.
Are AI agents covered by least privilege?
Yes.
If an AI agent can access data, APIs, tools, or systems, its authority should be limited to its approved task.
Is a service principal the same as an AI agent identity?
Not necessarily.
Traditional service principals commonly support predictable application workloads. New agent identity models provide more specific governance and traceability for AI agents.
Should unused permissions always be removed?
Unused access should be investigated.
If there is no valid business need, it should normally be removed.
If access is needed for rare tasks, document the reason.
The Takeaway
Least privilege is easy to write into a policy.
It is harder to prove.
For every service account, workload identity, service principal, bot, or AI agent, internal audit should answer:
If the evidence connects those answers, the organization can demonstrate least privilege.
If it cannot, the problem is not only documentation.
It may be an access-control gap.
Need Help Testing Least Privilege Under ISO 27001?
Canadian Cyber helps organizations review identity management, service accounts, workload identities, privileged access, AI agents, and Microsoft 365 environments.
We also help organizations test access-review evidence as part of ISO 27001 internal audits.
Our ISMS SharePoint Solution can centralize identity registers, access reviews, evidence, risks, findings, corrective actions, owners, and review dates.
Stay Connected With Canadian Cyber
Follow Canadian Cyber for guidance on ISO 27001 internal audits, least privilege, identity management, service accounts, AI agents, SharePoint ISMS, and access-control governance.
