Usually no. Human login flows assume interactive decision-making, visible consent, and a person who can notice anomalies. Agents need task-scoped access and clear offboarding. If the same login flow is reused, the organisation usually loses visibility into who or what actually used the session.
Why This Matters for Security Teams
Reusing employee login flows for AI agents blurs a basic security boundary: a person can approve a prompt, but an autonomous agent can keep acting after the human is gone. That creates a visibility problem for audit, incident response, and offboarding. Current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework points toward workload-specific controls rather than human-centric authentication reuse.
This matters because agents are goal-driven, can chain tools, and can trigger new actions based on intermediate outputs. When the same session is shared with a person, it becomes harder to prove which actions were human-approved, which were machine-executed, and which were simply unintended side effects. NHIMG has documented how AI agents move beyond intended scope in practice, and that pattern is visible in the OWASP NHI Top 10 analysis and the AI LLM hijack breach coverage.
In practice, many security teams encounter the identity problem only after an agent has already used a human session to touch systems that were never meant to be in scope.
How It Works in Practice
The safer pattern is to give the agent its own workload identity and issue access per task, not per employee session. That means the agent authenticates as an agent, not as a person, and authorisation is evaluated at request time based on intent, context, and policy. In mature setups, this usually means short-lived credentials, scoped tokens, and explicit revocation when the job ends.
Practitioners increasingly combine role-based access control with runtime policy checks, but RBAC alone is not enough for autonomous systems because the access pattern is dynamic. A better model is intent-based or context-aware authorisation: the agent requests access for a specific action, the policy engine checks the target, data sensitivity, environment, and risk, and only then issues a JIT credential. That aligns with the direction of the CSA MAESTRO agentic AI threat modeling framework and the OWASP Top 10 for Agentic Applications 2026.
- Use workload identity for the agent, such as cryptographic proof of the workload rather than a shared human session.
- Issue ephemeral secrets with tight TTLs and revoke them automatically after task completion.
- Separate approval from execution so the human authorises the goal, but the agent receives only the minimum technical access needed.
- Log tool calls, data access, and downstream actions so offboarding and incident response remain possible.
This approach also fits the broader NHI discipline described in NHIMG’s Ultimate Guide to NHIs, where credentials are managed for machines as machines. These controls tend to break down in legacy SSO environments where a single browser session is reused across humans, bots, and browser automation because the identity boundary is already collapsed.
Common Variations and Edge Cases
Tighter control often increases operational overhead, requiring organisations to balance speed against traceability. That tradeoff is real, especially where agents need to act frequently, touch many tools, or operate continuously. Best practice is evolving, but there is no universal standard for letting agents share employee login flows, and most security guidance now favours separation.
There are limited cases where a human-in-the-loop workflow may still use a shared application front end, but the agent should still receive its own backend identity and its own access token. The human can approve a task, yet the system should not translate that approval into a reusable employee session. This distinction becomes critical for regulated data, admin consoles, and environments with lateral movement risk. NHIMG’s Moltbook AI agent keys breach shows why exposed secrets and overbroad agent access quickly become an enterprise incident.
For organisations standardising the model, the most practical path is to treat agent identity as a separate control plane and to anchor governance to NIST AI Risk Management Framework and the Anthropic AI-orchestrated cyber espionage campaign report as evidence that autonomous behaviour changes the threat model. In hybrid estates, the guidance breaks down when identity governance cannot distinguish person, service, and agent at the token level.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agent autonomy and tool use create mis-scoped access risks. |
| CSA MAESTRO | TA-1 | MAESTRO addresses agent identity, control, and threat modeling. |
| NIST AI RMF | GOVERN | AI RMF governance covers accountability for autonomous agent actions. |
Assign ownership, logging, and review for every agent that can act without direct human input.
