Notifications
Clear all
Topic starter
20/08/2026 5:48 pm
TL;DR: Black Hat 2025 conversations showed agentic AI shifting security concerns from content generation to action-taking systems, with long-standing weaknesses in RBAC, API security, session handling, and third-party trust becoming more exposed as AI workflows scale, according to ActiveFence. The governance lesson is that AI security must be continuous and identity-aware, because delegated machine actions now create blast-radius problems that annual reviews cannot contain.
NHIMG editorial — based on content published by ActiveFence: Alice at Hacker Summer Camp: Black Hat 2025 Key Takeaways
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring.
Q: Why do AI agents create new risk in non-human identity management?
A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts.
Q: What do teams get wrong about RBAC for AI systems?
A: They assume a role definition is enough to control behaviour.
Practitioner guidance
- Define agent-level identity boundaries Assign each AI agent a discrete identity, then bind it to task-scoped credentials, approved tools, and explicit session expiry so access cannot outlive the work it was meant to do.
- Separate human approval from runtime authority Require policy checks at execution time, not only at onboarding or deployment, so an approved workflow cannot silently expand into new systems, datasets, or connector paths.
- Inventory fourth-party AI dependencies Map every external model, connector, and embedded AI service to the credentials and permissions it inherits, including hidden downstream trust chains that procurement reviews often miss.
What's in the full article
ActiveFence's full blog covers the operational detail this post intentionally leaves for the source:
- Black Hat session references and practitioner anecdotes that show how AI risk is being discussed in the field
- Specific examples of the RBAC, API security, and session management issues observed across AI implementations
- The article's proof-of-concept and safety guidance for teams testing AI systems against attacker-style scenarios
- Vendor-specific context on how ActiveFence positions its own AI risk-scoring approach
👉 Read ActiveFence's analysis of Black Hat 2025 AI security and agentic risk →
Agentic AI security at Black Hat 2025: what changed for teams?
Explore further
20/08/2026 6:28 pm
Agentic AI is becoming a governance problem before it becomes a model problem. The core issue is that organisations are deploying systems that can take actions, not just generate outputs, while still governing them with controls designed for static software. That mismatch creates a control gap across IAM, PAM, and third-party oversight. The practitioner conclusion is straightforward: if the agent can act, it must be governed like a privileged runtime principal.
A question worth separating out:
Q: How should organisations respond when third-party AI tools expand the trust chain?
A: They should extend vendor review beyond the primary supplier to connectors, embedded models, and downstream services that inherit credentials or data access. The goal is to see the full machine-to-machine trust chain, then decide where access can be reduced, segmented, or isolated before production use.
👉 Read our full editorial: Agentic AI security now hinges on continuous threat modelling
