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.
Related resources from NHI Mgmt Group
- What do organisations get wrong when they focus only on discovering AI agents?
- What do organisations get wrong when they onboard AI agents into IAM workflows?
- What do organisations get wrong when they assume more open AI access automatically means less risk?
- What do organisations get wrong when they scale AI agents without a data security platform?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
