What do organisations get wrong when they deploy AI agents on top of open-weight models?

They often treat the model as the project and assume the surrounding plumbing is secondary. The real failure points are hardcoded credentials, unauthenticated inference endpoints, unreviewed MCP connections, and maker mode agents that inherit the creator’s access. Those design choices create privilege escalation paths that have nothing to do with the model weights themselves and everything to do with entitlement discipline.

Where the deployment failure really starts

Organisations usually misread agentic risk as a model quality problem when it is mostly a deployment design problem. Open-weight models are only one layer in a larger system that includes credentials, tool access, endpoint trust, and runtime permissions. If those surrounding controls are weak, a capable model can still become an easy path to unintended data access or action.

The practical mistake is treating inference as the boundary. AI agents do not need a flawed model to cause harm if they can reach secrets, call tools, or inherit privileges that were never meant for autonomous use. That is why the real subject is entitlement discipline, not just model selection.

One useful way to think about this is that the model generates decisions, but the environment determines blast radius. A clean model wrapped in loose access control can be more dangerous than a less capable model wrapped in tight authentication, scoped credentials, and verified tool permissions.

What organisations typically get wrong about credentials and tool trust

Hardcoded credentials, unauthenticated inference endpoints, and overly broad connectors are the most common avoidable errors. Once an agent can call a tool without strong identity checks, the tool chain becomes an attack surface, not just an automation layer. Unreviewed MCP connections are especially risky because they can silently expand what the agent can see and do across systems.

Maker mode is another common failure pattern. When the agent inherits the creator’s access, the system often converts personal convenience into production-grade privilege. That creates a hidden gap between who built the workflow and what the agent is allowed to do at runtime, especially when the original creator had broad access for development, testing, or debugging.

Open-weight models can accelerate this problem because they lower the barrier to self-hosting and rapid integration. The technical temptation is to focus on model provenance, prompting, or benchmarks, but those are secondary if the agent can authenticate too easily, reuse long-lived secrets, or operate with no clear separation between human and machine authority.

For a broader view of how agent systems fail in practice, NHIMG’s AI Agents: The New Attack Surface report and the AI Agent Identity Security: The 2026 Deployment Guide both focus on the access and lifecycle mistakes that create these failures.

Why model-centric thinking misses the actual attack path

The attack path usually runs through identity, secrets, and authorization, not through the weights themselves. An attacker who can abuse an exposed endpoint, steal a token, or exploit an overprivileged connector may never need to compromise the model. That is why AI agent security often looks more like access governance and API security than model hardening.

This also explains why prompt injection and tool misuse matter so much in agent deployments. The model may be the decision engine, but the tool call is where the consequence happens. If the agent can be induced to act on untrusted instructions while holding real privileges, the result can be data exposure, lateral movement, destructive change, or credential abuse.

Good practice therefore requires reviewing not just what the agent can infer, but what it can reach, impersonate, delegate, and persist across sessions. If those boundaries are not explicit, the organisation has effectively turned convenience into an ungoverned privilege layer.

For a standards view of the same problem space, the OWASP Agentic AI Top 10 and CSA MAESTRO agentic AI threat modeling framework both map the risk to identity, tool use, supply chain, and autonomy, which is where the real exposure sits.

Risk and Threat Considerations

When organisations put agents on top of open-weight models without strict entitlement controls, they create a privilege-escalation path that is attractive to both opportunistic attackers and internal misuse. The main exposure is not model theft, it is unauthorised action through trusted integration points.

Failure mechanism: The agent inherits or is granted access through hardcoded secrets, weak endpoint protection, overbroad MCP or tool permissions, or creator-level access that was never meant for autonomous execution.

Impact: Attackers or misconfigured workflows can exfiltrate data, impersonate authorised users, invoke destructive actions, or move laterally through connected systems without needing to break the model itself.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	Hardcoded secrets and token exposure directly drive agent abuse.
	NHI-05 — Overprivileged NHI	Creator-level or broad runtime access turns agents into privilege escalation paths.
	NHI-07 — Long-Lived Secrets	Long-lived tokens and keys make agent compromise persist across sessions.
Recommendation — Eliminate embedded secrets and rotate any credential an agent can reach. Scope agent permissions to the minimum runtime access needed. Replace durable credentials with short-lived, task-scoped credentials.
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	The core failure is agents inheriting or abusing excessive authority.
	ASI02 — Tool Misuse	Unreviewed tool and MCP connections let agents invoke dangerous actions.
	ASI10 — Rogue Agents	Unbounded maker-mode agents can act outside intended governance.
Recommendation — Bind each agent action to a distinct identity and least-privilege policy. Allow only reviewed, explicitly authorised tools for each agent. Contain agent autonomy with approval gates and runtime enforcement.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	The answer hinges on secret handling, rotation, and lifecycle control.
	IA-9 — Service Identification and Authentication	Agents and tool endpoints must authenticate each other before action is allowed.
	AC-6 — Least Privilege	Agents should not inherit creator-level or broad production permissions.
Recommendation — Manage agent credentials with rotation, revocation, and protected storage. Require mutual authentication for agent-to-service interactions. Restrict each agent to the minimum access needed for its task.
NIST Zero Trust (SP 800-207)	Zero Trust Architecture	The answer depends on verifying every agent, endpoint, and tool request instead of assuming trust.
Recommendation — Treat every agent request as untrusted until explicitly verified.

Practitioner Guidance

What to prioritise: Start with the credentials and connectors before tuning prompts or model selection. If an agent can reach production systems, its authentication, token scope, and tool permissions deserve the first review because they define blast radius.

What to verify: Confirm that every agent action is tied to a distinct runtime identity, that secrets are not embedded in code or configuration, and that MCP or similar tool connections are explicitly approved and scoped. If the agent cannot be cleanly separated from the creator’s access, treat that as a design defect rather than a deployment detail.

Practitioner takeaway: The model is rarely the main security boundary, the entitlement model is. If organisations do not design for least privilege, short-lived access, and explicit tool trust, they will keep building agents that are powerful enough to cause incidents and weak enough to be abused.