What should organisations do first when adopting agentic development?

Start by discovering where agents already exist, then bind each one to an owner, a purpose, and a constrained permission set. After that, enforce guardrails at the tool and pipeline layer so agents cannot reach unapproved MCP servers, packages, or secrets. The first goal is visibility, because you cannot govern what you cannot see.

Why This Matters for Security Teams

Agentic development changes the control problem. Traditional application security assumes a known service boundary, a human operator, and a relatively stable set of APIs. Agentic systems introduce autonomous software entities that can choose tools, chain actions, and reach into packages, data stores, and NIST AI Risk Management Framework guidance is useful here because the first step is not adding more policy, but understanding where the system can act, what it can touch, and who is accountable for it.

That matters because agents often appear informally long before they are approved. A developer may connect an LLM to a ticketing system, a CI pipeline may gain a summarisation bot with token access, or an internal workflow may quietly inherit an MCP server connection. Once those paths exist, the risk is not just misuse. It is also drift, where no one can say which agent has which permissions or why those permissions were granted. Current guidance suggests treating this as a governance and inventory problem before it becomes a hardening problem.

In practice, many security teams encounter agent sprawl only after a data path, package chain, or secret exposure has already occurred, rather than through intentional design review.

How It Works in Practice

The first operational step is discovery. Organisations should identify where agents already exist, including prototypes, shadow automations, internal copilots, and workflow assistants embedded in build or support tooling. From there, each agent needs an owner, a declared purpose, and a permission boundary that is narrow enough to be audited. That includes tool access, model access, MCP server reachability, package installation rights, and secret usage. The goal is not to ban autonomy, but to make it explicit and bounded.

Practical implementation usually follows four moves:

• Inventory agent entry points across code repositories, CI/CD, chat interfaces, and orchestration platforms.
• Assign a business or engineering owner who can approve changes and accept residual risk.
• Classify tool actions by sensitivity, then block unapproved data sources, packages, and secret stores by default.
• Log tool calls and decision traces so security teams can review behaviour against policy and incident timelines.

This is where agentic guidance overlaps with OWASP Agentic AI Top 10 and the broader OWASP Top 10 for Agentic Applications 2026, which both emphasise tool abuse, over-permissioning, and unsafe orchestration patterns. It also aligns with the CSA MAESTRO agentic AI threat modeling framework, which is helpful when mapping where an agent can be manipulated through prompts, tools, or downstream systems.

Teams should also look at threat behaviour. MITRE ATLAS adversarial AI threat matrix is useful for reasoning about how attackers can influence model output, tool selection, or agent workflow integrity. These controls tend to break down when agents are embedded inside legacy automation platforms that do not support granular tool authorization, because permissions, logging, and runtime boundaries are too coarse to enforce safely.

Common Variations and Edge Cases

Tighter control often increases delivery overhead, requiring organisations to balance speed of experimentation against the cost of governance. That tradeoff is real, especially in teams that are iterating quickly on agent prototypes. Best practice is evolving, but current guidance suggests separating sandbox experimentation from production-grade autonomy so teams can move fast without granting broad access too early.

There is also no universal standard for naming or classifying agent types yet. Some organisations distinguish between assistants, task agents, and orchestrators, while others use a single control model across all three. The important point is consistency: if one team treats an agent like a script and another treats it like a privileged service account, policy gaps will appear.

Intersection with identity becomes important when agents act on behalf of users or service accounts. In those cases, non-human identity governance should include service identity lifecycle, secret rotation, and explicit delegation rules. That is especially important when agents can invoke APIs, create tickets, or trigger deployments with human-derived authority. Research-led practitioners also treat disclosure controls carefully when a system can reach sensitive content or regulated data, because output validation alone does not stop overbroad access at the source.

For broader governance alignment, NIST AI RMF remains the anchor for accountability, while emerging agentic guidance such as Anthropic’s first AI-orchestrated cyber espionage campaign report shows why autonomous action deserves explicit oversight rather than assumed trust.

Related resources from NHI Mgmt Group

• Should organisations replace static secrets before adopting more agentic workflows?
• What should organisations review before adopting agentic API access controls?
• How should organisations govern context poisoning in agentic development tools?
• What should organisations test before adopting agentic AI in security operations?