Notifications
Clear all
Topic starter
18/08/2026 2:10 pm
TL;DR: Blocking developers inside agentic workflows simply pushes risk into shadow workarounds, while safer tooling, scoped secret delivery, and visibility into agents, MCPs, and harnesses reduce that risk without slowing delivery, according to LEGIT Security. The core issue is governance: when code and actions are generated by agents, trust must move from human judgment to observable control points.
NHIMG editorial — based on content published by LEGIT Security: Why the answer to secure agentic development isn't tighter restrictions - it's better developer tooling
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.
Questions worth separating out
Q: How should security teams control AI-assisted coding without slowing developers down?
A: Put policy into the IDE so security guidance appears during code creation, not after commit.
Q: Why do blocked AI workflows often create more risk instead of less?
A: Blocked workflows rarely stop intent.
Q: What do security teams get wrong about secrets in agentic development?
A: They often treat secret leakage as a prompt hygiene problem when it is really a lifecycle and storage problem.
Practitioner guidance
- Define approved secret handoff flows for agent sessions Replace copy-paste secret sharing with scoped, session-bound delivery that uses an approved mechanism tied to user intent, expiration, and revocation.
- Inventory every agent, MCP, model, and harness in use Build a live register of tools and integrations on developer endpoints so security can see which capabilities exist and which ones fall outside the standard toolset.
- Require provenance checks for agent-generated code Flag code entering the pipeline if it did not pass through approved agentic controls, then route it back to the originating team for review and process correction.
What's in the full article
LEGIT Security's full analysis covers the operational detail this post intentionally leaves for the source:
- Internal rollout pattern for gating dangerous agent actions without breaking developer flow
- How the team injects secrets into agent sessions through an approved MCP-based path
- The visibility model for discovering installed agents, models, harnesses, and skills across endpoints
- The internal policy approach used to identify code that bypassed approved agentic controls
👉 Read LEGIT Security's analysis of secure agentic development and developer tooling →
Agentic development security: are your controls creating workarounds?
Explore further
18/08/2026 3:03 pm
Safe paths are the real control in agentic development. Hard blocking tools inside a developer workflow does not eliminate risk, it redistributes it into shadow processes the security team cannot see. In agentic environments, governance must make the secure path easier than the unsafe one, or users will route around the control. That is a design principle, not a convenience feature, and it should shape developer tooling decisions immediately.
A question worth separating out:
Q: Who is accountable when an AI coding tool introduces insecure code into production?
A: Accountability stays with the organisation that allowed the tool to operate without enforced guardrails. The model is not the accountable party. Security, engineering, and platform owners share responsibility for defining policy, enforcing it at runtime, and logging the decision trail that proves controls were applied.
👉 Read our full editorial: Agentic development needs safer developer paths, not harder blocks
