They should govern them as non-human identities. The article shows that these agents have ownership, privileges, lifecycle events, and audit implications that look much more like workloads than product features. Treating them as features underestimates the need for scoping, review, monitoring, and offboarding across the full identity lifecycle.
Why in-platform agents belong in the identity model
In-platform agents are not just interface conveniences. They are acting entities with ownership, delegated authority, credentials, and operational side effects, which means they change the control model in the same way a workload or service account does. If you govern them as features, you usually miss who owns them, what they can do, and how they are revoked when the underlying need ends.
The practical test is whether the agent can act independently enough to create security-relevant outcomes. If it can open tickets, move data, trigger workflows, call APIs, or interact with production systems, then the governance question is not product management, it is identity and access control. That is why the identity boundary matters more than the user interface boundary.
For a useful comparison of the underlying governance difference, Human vs Non-Human Identity shows why ownership, lifecycle, and delegated access have to be treated explicitly rather than assumed away.
What changes when the agent is governed as a non-human identity
Once an in-platform agent is governed as a non-human identity, the organisation has to answer the same questions it would ask for any other privileged actor: who owns it, how it authenticates, what it is allowed to do, where its secrets live, and when it must be disabled. That shifts the control objective from “is this feature enabled?” to “is this actor bounded, reviewable, and removable?”
This framing also changes auditability. Identity-based governance creates a record of creation, approval, privilege assignment, monitoring, recertification, and offboarding. Feature-based governance often stops at product configuration and does not preserve the evidence needed to explain why the agent existed, who approved its access, or whether access was later reduced.
Operationally, the difference shows up in privilege design. Agents that are treated as identities can be scoped with least privilege, separated by environment, and reviewed for entitlement creep. If they are treated as features, teams tend to over-rely on broad application permissions and shared credentials, which makes later containment harder.
NHIMG’s Ultimate Guide to NHIs is the clearest broad reference point for the lifecycle, visibility, rotation, and offboarding concerns that appear once these agents are treated as identities.
How to govern them in practice without overcomplicating the product
The right governance model is usually lightweight in process but strict in boundaries. A practical setup separates product ownership from identity ownership, so the team that ships the agent does not also become the only team able to approve its standing privileges. That separation is important because agent behaviour can drift long after the product itself is considered stable.
Review should focus on four controls: whether the agent still needs access, whether the permissions match current use, whether its credentials or tokens have an expiry or rotation path, and whether there is a defined offboarding step when the feature is retired or repurposed. If those controls are absent, the agent is already behaving like an unmanaged identity even if the product team still calls it a feature.
The strongest operating pattern is to inventory agents alongside other machine and workload identities, then attach monitoring and recertification to the same cadence used for sensitive service accounts. That makes the model scalable because it avoids inventing a separate governance regime for each platform feature. For a deeper treatment of ownership and accountability, NHI Ownership and Accountability Guide is directly relevant, and Agentic AI Identity Guide is useful when the agent delegates or acts on behalf of a user.
Risk and Threat Considerations
When in-platform agents are treated as features, organisations often lose sight of their privilege footprint and credential exposure. That creates a clean path for abuse, because an overprivileged or orphaned agent can become a durable access path even after the business reason for it has changed.
Failure mechanism: The agent inherits broad permissions, long-lived tokens, or shared credentials, then continues operating without the same review, rotation, or offboarding discipline applied to other identities.
Impact: Attackers or careless internal users can abuse that standing access to move laterally, exfiltrate data, trigger unauthorised actions, or preserve access after the original owner has forgotten the agent exists.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST Zero Trust (SP 800-207) and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | In-platform agents can accumulate excess permissions and standing access. |
| NHI-01 — Improper Offboarding | The question hinges on lifecycle and revocation when an agent is retired. | |
| NHI-07 — Long-Lived Secrets | Agent governance depends on managing tokens and other standing credentials. | |
| Recommendation — Constrain each agent to the minimum permissions needed for its task. Define an offboarding step that revokes access and disables the agent. Replace standing secrets with short-lived credentials and rotation controls. | ||
| NIST Zero Trust (SP 800-207) | AC-6 — Least Privilege Access | Identity-based control for agents aligns with bounded, verified access. |
| Recommendation — Enforce least privilege and continuous verification for each agent action. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The question is fundamentally about how to classify and govern agent access. |
| Recommendation — Place in-platform agents under the same IAM ownership and review model as other identities. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent identities become risky when privilege and authority are poorly bounded. |
| ASI10 — Rogue Agents | Unowned or poorly governed agents can persist and act outside intended control. | |
| Recommendation — Bind each agent to explicit authority boundaries and review privilege growth. Detect and retire agents that operate without current ownership or approval. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Agents with standing access can be abused as valid accounts. |
| Recommendation — Hunt for abuse of legitimate agent accounts and revoke unnecessary access paths. | ||
Practitioner Guidance
What to verify: Confirm that every in-platform agent has a named owner, a documented purpose, a bounded permission set, and a defined retirement path. If any of those are missing, governance is incomplete even if the feature is working as intended.
Decision rule: If the agent can authenticate independently, hold secrets, or act across system boundaries, govern it as an identity. If it only changes a local UI behaviour and cannot create security-relevant side effects, feature-level governance may be enough.
Common mistake: Teams often assume that because the agent is embedded in a product, the product team’s normal release process is sufficient. In practice, lifecycle review, access review, and offboarding need to be explicit or the agent accumulates invisible privilege.
Practitioner takeaway: The governance model should follow the power to act, not the packaging of the feature; once an agent can execute meaningful actions, it needs identity-style control.