Notifications
Clear all
Topic starter
02/08/2026 11:46 am
TL;DR: AI agents call APIs, trigger workflows, and modify systems after the model layer, leaving most security tooling blind to the actions that create real risk, according to Salt. The action layer, not prompt security alone, is where agentic governance becomes operationally necessary.
NHIMG editorial — based on content published by Salt: AI agent action-layer security and the limits of model-layer protection
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 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 autonomous AI agents create more access risk than task bots?
A: Autonomous AI agents create more access risk because they can combine persistence, reactivity, and initiative.
Q: What breaks when organisations only secure the model layer of agentic AI?
A: They miss the point where decisions become actions.
Practitioner guidance
- Map agent-to-system trust chains Document every API, MCP server, workflow engine, and downstream system an agent can reach, then assign an owner for each connection.
- Baseline normal agent behaviour Define expected call patterns, frequencies, payload types, and sequence logic for each agent before you depend on it in production.
- Govern agent credentials as NHI Treat agent secrets, tokens, and service accounts as non-human identities with lifecycle ownership, rotation, and revocation rules.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- How its Agentic Security Graph correlates agents, MCP servers, technologies, and third-party vendors into one runtime view.
- What live traffic data and posture overlays are used to identify action-layer risk across connected systems.
- How the vendor describes behavioural baselining for agents across different infrastructure environments.
- Which implementation gaps it says most AI security tools miss when they stop at the model layer.
👉 Read Salt's analysis of AI agent action-layer security →
AI agents and the action layer: are your controls keeping up?
Explore further
02/08/2026 12:57 pm
Action-layer security is now an identity governance problem, not just an AI safety problem. Once an agent can call APIs and trigger workflows, it behaves like a software identity with delegated authority. That means IAM and NHI teams must govern what the agent can do, not just what model it runs on. The field needs a control model that treats runtime action as the primary security boundary, because that is where loss, abuse, and misconfiguration become real.
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.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
A question worth separating out:
Q: Who is accountable when an AI agent makes an unauthorised change?
A: Accountability should be assigned to the governance model that authorised the delegation, the owner of the workflow, and the team that set the policy boundary. In practice, organisations need clear responsibility for agent configuration, monitoring, and incident response because the machine’s speed does not remove human accountability for the delegated identity.
👉 Read our full editorial: Action layer security is the missing control for AI agents
