Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

AI agent actions and API visibility: what IAM teams need now


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 15051
Topic starter  

TL;DR: AI agents create risk when they take the wrong action, not just when they answer badly, because prompts can flow through runtimes, MCP servers, tools, and downstream APIs before security teams see the impact, according to Salt. The governance gap is visibility into who or what authorised the action, because agentic systems collapse traditional prompt-level controls into runtime decisions that IAM cannot review after the fact.

NHIMG editorial — based on content published by Salt: AI agents do not create risk only when they hallucinate or produce an inaccurate answer

By the numbers:

  • 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%).

Questions worth separating out

Q: How should security teams govern AI agents that call APIs instead of using a UI?

A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login.

Q: Why do AI agents complicate existing IAM and NHI controls?

A: They complicate control design because they can select actions at runtime, call multiple APIs, and move authority across systems without a human session boundary.

Q: What breaks when agent governance stops at the LLM layer?

A: What breaks is visibility into the actual business action.

Practitioner guidance

  • Map prompt-to-API execution paths Inventory every step from user input to downstream API action, including the application layer, agent runtime, MCP server, connector, and final service.
  • Scope MCP tools as privileged capabilities Review each MCP server for exposed tools, default permissions, and hidden access to sensitive data or admin workflows.
  • Preserve agent context in API telemetry Retain the originating prompt, selected tool, MCP server, and agent identifier alongside each API event.

What's in the full article

Salt's full analysis covers the operational detail this post intentionally leaves for the source:

  • A layer-by-layer walkthrough of agent runtime, MCP, and API interactions that implementation teams can use to build telemetry requirements
  • Specific examples of how contextual visibility is intended to help trace agent behaviour across connected tools and downstream services
  • Discussion of how the security graph approach fits into posture management for agents, tools, connectors, and APIs
  • Roadmap references to agentic protection features that are not detailed in this editorial analysis

👉 Read Salt's analysis of AI agent action risk, MCP visibility, and API control →

AI agent actions and API visibility: what IAM teams need now?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 14635
 

The governance failure is not prompt quality, it is action authority. Security programmes that stop at model safety assume the dangerous part of agentic AI is the text the model produces. In reality, the business risk appears when an agent is allowed to choose and execute a tool action that affects live systems. That shifts the governance question from answer correctness to runtime authorisation. Practitioners should treat every agentic workflow as an execution path that needs explicit access boundaries.

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.
  • Another finding from the same research shows only 52% of companies can track and audit the data their AI agents access, leaving 48% without complete compliance and investigation visibility.

A question worth separating out:

Q: Who is accountable when an AI agent makes the wrong change?

A: Accountability sits with the governance chain that approved the access model, not with the agent alone. Teams need a trace from requester to policy decision to identity issuance to action results. If that chain is missing, incident review becomes guesswork and access governance cannot be defended to auditors.

👉 Read our full editorial: AI agent risk is moving from prompts to API actions



   
ReplyQuote
Share: