What breaks when AI assistants can use the same tools for reading and changing systems?

Why This Matters for Security Teams

When AI assistants can both read from and write to the same systems, the security model stops being a simple query layer and becomes an action layer. That change matters because the assistant is no longer just summarising data. It can now change tickets, update configurations, trigger workflows, and chain tools in ways that are difficult to predict or audit after the fact.

This is where traditional separation of duties weakens. A role that is acceptable for observation is not automatically safe for modification, especially when the same session can move from diagnostics to execution without a human checkpoint. NIST’s control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls remains relevant here, but the practical question is how to translate it into tool-level boundaries for autonomous or semi-autonomous assistants.

NHIMG research on The State of Secrets in AppSec highlights how quickly sensitive access assumptions become operational risk once secrets, credentials, and automation are involved. In practice, many security teams encounter unsafe write access only after an assistant has already crossed from investigation into unintended system change, rather than through intentional design.

How It Works in Practice

The safest pattern is to treat read and write as separate trust zones. Read-only tools can be broadly available for discovery, summarisation, and triage. Write-capable tools should be gated, scoped, and time-bound, with explicit approval for high-impact actions. For agentic systems, current guidance suggests moving away from static role bundles and toward context-aware authorisation evaluated at request time.

That usually means three layers working together:

• Workload identity for the assistant itself, so the system can prove what is making the request, not just what credentials happen to be present.
• Just-in-time credential issuance, so write permissions are short-lived and tied to a specific task or approval window.
• Policy-as-code checks at the tool boundary, so each change request is evaluated against task context, environment, and risk.

For identity plumbing, teams often look to SPIFFE and SPIRE concepts for workload identity, because they separate the identity of the calling workload from the human user who initiated it. For governance, NIST AI Risk Management Framework helps frame accountability, while NHIMG’s LLMjacking research shows why exposed or overpowered credentials can turn an assistant into a rapid abuse path.

In practice, the write path should require an additional decision point when the assistant changes state, such as moving from “suggest” to “execute.” That is especially important when actions are irreversible, cross-system, or capable of causing lateral movement. These controls tend to break down when the assistant is wired directly into broad admin APIs because the tool layer becomes indistinguishable from full operator access.

Common Variations and Edge Cases

Tighter segmentation often increases workflow friction, requiring organisations to balance safety against speed. That tradeoff is real, especially in support, SRE, and security operations where assistants are expected to reduce response times. Best practice is evolving, and there is no universal standard for exactly where the read/write boundary should sit in every environment.

One common edge case is partial write access, where an assistant can create drafts, open tickets, or stage changes but cannot apply them. That can work well, but only if downstream systems enforce a second approval step. Another edge case is “safe write” automation, such as low-risk label updates or non-production configuration changes. Even then, policy should distinguish between reversible and irreversible actions.

Another failure mode appears in multi-tool chains. A seemingly harmless read operation can feed enough context into a later write action to bypass human review. This is why NHI governance should be paired with real-time policy evaluation, not just static permissions. The distinction matters most when one assistant session can span multiple systems, because the blast radius is defined by the chain, not by any single tool call.

For broader control mapping, NIST Cybersecurity Framework 2.0 helps anchor access governance, while the NHIMG article on DeepSeek breach is a reminder that exposed data and overbroad access become much more dangerous once automation can act on them directly.

Related resources from NHI Mgmt Group

• What breaks when employees use AI tools inside browser sessions without data controls?
• What breaks when AI agents can call tools after reading untrusted content?
• What breaks when employees use unapproved AI tools with company data?
• What breaks when AI security systems are allowed to detect and remediate in the same workflow?