Agentic AI and Infrastructure Access: Seven Identity Controls

What is changing?

Humans are no longer the only identities taking action

Applications and automation have accessed organisational systems for years. Agentic AI extends that familiar challenge: software can now select tools, make decisions and perform a sequence of actions with less direct human involvement. A control model designed mainly around a person signing in with a password may not identify the actor clearly, limit it to one task or explain what it did.

Cisco's August 2026 article on “Infrastructure Identity” argues for identifiable actors, short-lived task-specific privilege and attributable sessions instead of anonymous access, durable secrets and standing privilege. The article also announces a Cisco and Teleport strategic partnership, so it should be read as both a useful statement of the problem and a vendor announcement—not as the only possible solution.

The immediate lesson

An AI agent should not inherit broad or persistent access simply because automation needs to work quickly. Its access should be no wider or longer-lived than the task requires, and its actions should remain explainable to an accountable person.

Start with what already exists

Non-human identity is not a future AI problem

Microsoft defines a workload identity as an identity assigned to software such as an application, service, script or container. In Microsoft Entra, this includes applications, service principals and managed identities. Agent identities are a newer category, but the governance work begins with the whole machine-identity estate.

Applications and integrations

Business applications, API integrations and third-party services may hold delegated or application permissions that are broader than their current purpose.

Automation

Scripts, scheduled tasks, deployment pipelines and robotic processes may depend on service accounts, tokens, certificates or embedded secrets.

Managed identities

Cloud resources can authenticate without a stored password, but their permissions, ownership and lifecycle still need review.

AI agents

Agents may act autonomously or on behalf of a user. Their identity model should preserve the difference and prevent user context from becoming unrestricted authority.

A practical starting point

Do not wait for dozens of autonomous agents. First determine which non-human identities already exist, what they can reach, who owns them and whether their activity can be evidenced.

Practical review

Seven identity controls to review now

1

Inventory non-human identities

Record applications, service principals, managed identities, automation accounts, API keys, integrations and AI agents. Include purpose, environment, authentication method, last activity and the resources each identity can reach. Start with high-impact systems rather than waiting for a perfect enterprise inventory.

2

Assign an accountable owner and sponsor

Every identity should have a technical owner and a person accountable for its business purpose. Microsoft recommends an owner and sponsor for Agent ID identities. Smaller organisations can apply the same principle in a simple register, provided responsibility remains current when people or suppliers change.

3

Remove reusable secrets where practical

Prefer managed identities, workload identity federation, certificates or other short-lived token-based approaches supported by the platform. Do not assume a secret is safe merely because it sits in a vault: reduce its scope, rotate it, monitor its use and remove it when a secretless option becomes practical.

4

Apply least privilege and separate environments

Grant only the APIs, sites, data and administrative actions required for the defined task. Keep development and testing agents away from production resources. Avoid shared identities where separate identities would make permissions and activity clearer.

5

Avoid standing administrative privilege

Where the platform supports it, issue time-bound or task-specific access and end it when the work finishes. Add approval for consequential actions such as changing identity policy, deleting data, altering network controls or disrupting operational systems.

6

Log attributable actions and monitor behaviour

Logs should distinguish the agent or workload, any user on whose behalf it acted, the target resource and the outcome. Alert on unexpected APIs, unusual token activity, permission changes, new credentials and access outside the agent's normal pattern. Retain evidence in line with incident and compliance needs.

7

Govern the complete lifecycle

Approve identities before production use, review access periodically and disable them quickly when risk changes. Remove abandoned agents, unused service principals and stale credentials. Test the kill switch, incident response and safe recovery path before relying on an agent for important operations.

Resource-aware implementation

You do not need a sophisticated platform to begin

Dedicated agent-identity products may be appropriate at scale, but buying one is not the first control. A smaller organisation can begin with an owned register, permission review, secret inventory, access logs and clear approval rules for high-impact actions.

Know the actorGive each material agent or workload a distinct, recognisable identity wherever the platform allows it.

Know the purposeDocument why it exists, the task it performs and the data or systems it is allowed to use.

Know the boundaryRecord permitted resources, prohibited actions, expiry or review date and when human approval is required.

Know the evidenceConfirm where sign-ins, token requests, tool calls, configuration changes and administrative actions are recorded.

Care and charity environments

An overprivileged agent with access to identity, networking, infrastructure or operational systems could make disruptive changes faster than a person can review them. Protect service continuity: pilot with non-sensitive data, constrain production access, require human approval for high-impact actions and keep a tested manual fallback.

RACF-CC alignment

Treat agent identity as a cross-domain control

This work starts in Domain 1: Identity & Access Management, but it also depends on secure connectivity and segmentation, monitoring and detection, incident response and governance and risk.

Introduce access safely

Inventory → assess → pilot → validate → constrain → monitor → review

Begin with observation and low-risk tasks. Validate identity, permission and logging behaviour before allowing consequential actions. Expand only when the evidence shows that access is bounded, attributable and recoverable.

Sources and context

Agentic AI and infrastructure access: Seven identity controls to review now