Topic starter
01/07/2026 2:00 am
TL;DR: Claude Tag gives a shared AI agent its own identity, credentials, and permissions inside Slack, so downstream systems see the agent rather than the human requester, according to Zenity. The governance problem shifts from user access to runtime control over what the agent is allowed to do before each tool invocation.
Editorial analysis by NHI Mgmt Group, based on content published by Zenity: “Claude Tag Didn’t Create Another Identity Problem. It Created a Control Risk.”.
Key questions
Q: What breaks when AI agents are given broad inherited permissions?
A: Broad inherited permissions break the assumption that access is tied to a narrow business need.
Q: Why do shared AI agents create more risk than user-bound assistants?
A: Because permissions belong to the agent, not the individual requester, so one identity can execute work for many people.
Q: How can security teams tell whether AI lifecycle controls are working?
A: They should look for evidence that access requests, policy enforcement, and usage visibility are centrally recorded and current.
Practitioner guidance
- Define the shared agent as the governed principal Map each shared AI agent to a named owner, a permission boundary, and a revocation path so the agent can be reviewed independently of any single requester.
- Insert policy checks before each tool call Require runtime authorisation before GitHub, Jira, CRM, data warehouse, or MCP actions execute, because post-event review cannot prevent the unsafe call itself.
- Separate requester logs from execution logs Correlate the Slack requester, the agent identity, and the downstream system action in one workflow so investigators can reconstruct intent and impact without manual log stitching.
Bottom line: Shared AI agents move the decisive control point from the user to the agent's runtime permissions and tool calls.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
01/07/2026 2:18 am
Claude Tag is a control-risk change, not just an identity change. The article's central insight is that the security boundary moves from the human user to the shared agent's runtime permissions. That means the primary governance question is no longer who may ask, but what the agent may do once a request is accepted. For IAM and NHI teams, the practical conclusion is that shared agents must be governed as active execution principals, not as passive interface layers.
A few things that frame the scale:
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when AI agents use shared credentials across workflows?
A: Accountability belongs to the organisation that owns the credential lifecycle and the policy attached to it. When shared secrets are used across humans, agents, and machines, the governance model must still identify which actor used the credential, under what approval path, and for what task. Without that, accountability becomes ambiguous.
👉 Read our full editorial: Claude Tag shifts enterprise AI from identity to control risk