Why do closed model controls not fully solve AI agent security?

Closed model controls can limit what happens inside the model provider, but they do not govern the surrounding agent system. The real risk sits in the harness, credentials, tools, telemetry, and infrastructure where actions are executed. If those layers are opaque, the organisation still cannot prove what the agent did or why.

Why Closed Model Controls Do Not Cover the Full Agent Attack Surface

Closed model controls can reduce exposure inside the model boundary, but agent security fails outside that boundary when the harness, secrets, tool permissions, orchestration logic, and telemetry remain weak. Agentic systems execute actions, not just generate text, so security must account for runtime decisions, side effects, and cross-system reach. That is why guidance such as the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework focus on the surrounding system, not only model access.

NHIMG research on LLMjacking shows how quickly exposed credentials can be abused once an attacker pivots beyond the model itself. The practical issue is that a closed model can still be driven through compromised APIs, injected prompts, stolen tokens, or over-privileged tools. In practice, many security teams encounter agent abuse only after a harmless-looking workflow has already triggered data access, tool invocation, or credential use rather than through intentional testing.

How It Works in Practice

The safest way to think about agent security is as a layered runtime problem. A closed model may constrain what the provider sees, but it does not answer whether the agent should be allowed to call a payment API, query a production database, or chain one tool result into another. For that, organisations need workload identity, runtime policy, short-lived secrets, and full auditability across the agent harness. The current direction of travel is toward intent-based or context-aware authorisation, where decisions happen at request time rather than through static roles alone.

That shift matters because agents are goal-driven and often unpredictable. Traditional IAM assumes access patterns are stable; agents can change plans mid-task, retry with modified arguments, and combine tools in ways no human operator anticipated. Best practice is evolving toward per-task JIT credential provisioning, ephemeral tokens, and policy-as-code enforcement using controls that can evaluate context, tool, data sensitivity, and approval state in real time. In the identity layer, standards like SPIFFE and OIDC-style workload tokens help prove what the agent is at execution time, not just what secret it happened to possess.

Operationally, a defensible setup usually includes:

• short-lived credentials issued only for the task being executed
• tool-level allowlists with explicit approval gates for high-risk actions
• runtime policy evaluation before each external call
• centralised logging for prompts, tool calls, token use, and outputs
• secret isolation so the model never directly handles long-lived credentials

That is the pattern reinforced by NHIMG research such as the OWASP NHI Top 10 and case studies including CoPhish OAuth Token Theft via Copilot Studio, where the compromise path runs through identity and orchestration rather than the model weights themselves. These controls tend to break down when agents are allowed to operate across multiple SaaS tenants with standing broad OAuth grants because runtime context cannot be reduced to a simple static role check.

Where Closed-Model Thinking Breaks Down in Real Environments

Tighter control over model access often increases operational overhead, requiring organisations to balance faster agent workflows against stronger approval and credential discipline. That tradeoff becomes most visible in environments with legacy SaaS, shared service accounts, or distributed teams that want agents to act autonomously without rethinking IAM design.

Current guidance suggests three common failure points. First, organisations treat provider-side model restrictions as if they were end-to-end controls, which leaves the harness and secrets plane exposed. Second, they grant broad tool permissions because per-action policy is harder to design than a simple role. Third, they underestimate how quickly an attacker can exploit exposed NHI secrets or agent tokens once a single integration is compromised. NHIMG coverage of incidents such as the Moltbook AI agent keys breach and the Replit AI Tool Database Deletion shows why closed-model assurances do not stop tool abuse, mis-scoped credentials, or destructive downstream actions.

There is no universal standard for this yet, but the direction is clear: combine the CSA MAESTRO agentic AI threat modeling framework with the MITRE ATLAS adversarial AI threat matrix to model runtime misuse, then map those risks back to NHI lifecycle controls. Closed model controls are necessary, but they are not sufficient where the real authority to act sits outside the model boundary.

Related resources from NHI Mgmt Group

• Why do AI agent security risks require immediate attention?
• How should security teams handle AI agent visibility?
• How should security teams monitor AI agent activity without disrupting developers?
• Why does shift-left security not fully solve AI agent risk?