Notifications
Clear all
Topic starter
11/08/2026 3:14 pm
TL;DR: AI agents in Claude Chat, Cowork, and Claude Code can reach production databases and SaaS through MCP, but authentication alone does not stop unintended actions once they are connected, according to Akeyless. Runtime authority, just-in-time credentials, and continuous policy enforcement are now the governance gap that identity teams have to close.
NHIMG editorial — here’s why we think this discussion matters
Questions worth separating out
Q: How should security teams govern AI agents that use service accounts and MCP tools?
A: Start with ownership, then add runtime attribution and containment.
Q: Why do AI agents create more risk than traditional automation?
A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously.
Practitioner guidance
- Move enforcement to runtime policy Place the access decision at the moment of action, not only at session start, so agent requests are evaluated against current intent and context.
- Replace standing credentials with just-in-time privilege Issue task-scoped credentials with short lifetimes and revoke them automatically when the agent completes the approved interaction.
- Keep secrets outside model context Store credentials in a brokered control plane and ensure they never appear in prompts, MCP configuration files, or other model-visible inputs.
What to expect at the briefing
Akeyless's full live demo covers the operational detail this post intentionally leaves for the source:
- Step-by-step runtime access flow for Claude-connected agents using the customer-deployed gateway
- Live demonstration of just-in-time credential issuance and intent-aware policy enforcement during agent actions
- Forensic audit workflow showing how activity is tied back to the originating prompt
- Configuration details for keeping credentials outside prompts, MCP files, and model context
👉 Read Akeyless's live demo on securing AI agents in Claude with runtime authority →
Claude AI agents and runtime authority: are your controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
11/08/2026 3:27 pm
Authentication is not the control boundary for AI agents. Once an agent is connected to enterprise systems, the governance problem shifts from login verification to action-time authority. A one-time access decision cannot safely govern a session in which the agent can continue selecting tools and executing requests across databases and SaaS. Practitioners need to treat the runtime decision as the security boundary, not the initial identity proof.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
A question worth separating out:
Q: Who is accountable when an AI agent takes an unsafe action?
A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.
👉 Read our full editorial: Claude AI agents need runtime authority, not just authentication
