Notifications
Clear all
Topic starter
02/08/2026 12:04 pm
TL;DR: Agentic AI assistants in chat and SaaS environments can inherit user privileges, retain context, and execute actions at machine speed, creating detection and response gaps that resemble identity abuse more than app compromise, according to D3. The key failure is treating these systems as tools instead of identities with privileges, which collapses monitoring, attribution, and containment assumptions.
NHIMG editorial — based on content published by D3: Agentic AI assistants are showing up in Slack, Teams, WhatsApp, Telegram, Discord and they are more than just chatbots
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern personal AI assistants that act on behalf of employees?
A: Treat each assistant as a distinct non-human actor with its own identity, policy scope, and audit trail.
Q: Why do agentic identities create more risk than ordinary automation?
A: Agentic identities create more risk because they can act continuously, make decisions at runtime, and execute work at machine speed.
Q: What do security teams get wrong about Shadow AI?
A: They often treat Shadow AI as an approval problem for software, when it is usually also an identity problem.
Practitioner guidance
- Inventory every assistant with delegated access Create a register of chat-based, SaaS-based, and local agent runtimes, then record who owns them, what data they can access, and which tokens or scopes they use.
- Restrict OAuth and messaging scopes by default Review assistant permissions for read history, file access, post-as-user, admin-like scopes, and long-lived refresh tokens.
- Correlate identity and endpoint telemetry Use source IP, user agent, consent logs, and endpoint process evidence together so machine-speed action can be distinguished from human activity.
What's in the full article
D3's full post covers the operational detail this post intentionally leaves for the source:
- Specific first-hour SOC triage questions for suspected assistant abuse across messaging, OAuth, and endpoints
- Detailed containment steps for revoking integrations, disabling service principals, and preserving evidence
- Signal examples for distinguishing human activity from assistant-driven machine-speed actions
- Telemetry hints for local runtimes, browser extensions, and cloud-only assistant deployments
👉 Read D3's analysis of agentic assistant abuse in Slack, Teams, and SaaS workflows →
Agentic AI assistants in Slack and Teams: what SOC teams miss?
Explore further
02/08/2026 1:09 pm
Agentic assistants should be governed as identities with delegated authority, not as convenience features. The article’s core insight is that these systems can read, store, and act across multiple platforms, which places them inside the identity plane rather than the application layer. That is why messaging controls, OAuth governance, and endpoint telemetry all matter at once. The practitioner conclusion is simple: if the system can act as the user, it belongs in identity governance.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Who is accountable when an assistant acts on a user’s behalf?
A: Accountability should follow the owning identity, the approved application owner, and the control owner for the permissions in play. If the assistant is using a user token, the human may be visible in logs, but the governance issue is still the delegated system and the team that approved its access.
👉 Read our full editorial: Agentic AI assistants are becoming identity risks, not just chat
