Notifications
Clear all
Topic starter
23/06/2026 9:07 pm
TL;DR: Agent building remains brittle because today’s LLM workflows still require heavy human oversight, produce inconsistent outputs, and expose real systems and APIs while operating with weak error handling and unclear access boundaries, according to Aembit. That makes agentic AI an IAM problem now, not a future one.
NHIMG editorial — based on content published by Aembit: the limits of simple agent workflows and the need for runtime access control
Questions worth separating out
Q: How should security teams govern AI agents that can call tools and access real systems?
A: Treat each agent as a workload identity with explicit scope, short-lived access, and tightly controlled tool permissions.
Q: Why do AI agents create new IAM risks even when the model output looks acceptable?
A: Because acceptable-looking output does not mean safe execution.
Q: What breaks when agents are allowed to keep retrying until they succeed?
A: Unlimited retry loops turn small errors into repeated access attempts, repeated tool calls, and repeated exposure to the same failure state.
Practitioner guidance
- Scope agent identities to individual tasks Bind each agent to a narrow workload identity, then limit that identity to the minimum tools, APIs, and data paths required for the specific run.
- Separate reasoning from execution authority Keep critique, planning, and tool invocation under different permissions where possible, so a model that drafts an action cannot also execute it by default.
- Instrument tool-use visibility end to end Log the final prompt, tool call, tool response, and any framework transformation so investigators can reconstruct what the agent actually did.
What's in the full article
Aembit's full post covers the operational detail this post intentionally leaves for the source:
- Detailed walkthrough of the three-agent setup and how the critic and fixer loop was wired
- LM Studio and CrewAI configuration lessons that affect how agents talk to local models
- The exact debugging issues seen when tool calls were not executed as expected
- Practical observations on how agent frameworks behave when prompts, outputs, and actions blend together
👉 Read Aembit's analysis of how simple agents expose IAM and governance gaps →
Agentic AI governance: are your controls keeping up with runtime behaviour?
Explore further
25/06/2026 2:15 am
Agentic AI introduces an access-governance problem before it becomes a model-risk problem. The article shows that even simple agents can touch real systems, real APIs, and real data while operating with inconsistent output quality. That means the first control failure is not hallucination, it is uncontrolled runtime access. For practitioners, the implication is that agent governance must start with identity scope, not with prompt quality.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
- In the same research, organisations maintain an average of 6 distinct secrets manager instances, which fragments control and weakens central oversight.
A question worth separating out:
Q: How do teams know whether an agent is safe enough for production use?
A: Look for evidence that the agent can be contained by identity scope, observable tool use, and clear stop conditions. If the team cannot prove what the agent accessed, why it accessed it, and when it should have stopped, the system is not yet ready for production handling of sensitive workflows.
👉 Read our full editorial: Agentic AI foundations are still fragile without runtime access control
