Read-Only SQL

Expanded Definition

Read-only SQL is a constrained query pattern that allows an AI agent or automation workflow to inspect relational data without issuing INSERT, UPDATE, DELETE, DDL, or privilege-changing commands. In NHI security, the distinction matters because the query path is part of the identity boundary, not just the application boundary.

Usage in the industry is still evolving, especially where vendors label connectors as “read only” even when the underlying account can still write elsewhere in the environment. NHI Management Group treats true read-only SQL as a combined control: database permissions, connection scope, and agent tool policy all have to align. That framing is consistent with NIST Cybersecurity Framework 2.0, which emphasizes least privilege and controlled access paths.

The most common misapplication is assuming a query interface is safe because the prompt says “read only,” which occurs when the database account, service token, or downstream stored procedure still has write capability.

Examples and Use Cases

Implementing read-only SQL rigorously often introduces operational friction, because teams must balance faster agent-driven analysis against tighter schema and permission boundaries.

• An AI agent queries incident telemetry tables to summarize failed login spikes, but its database role cannot alter records or create objects.
• A support workflow lets an LLM inspect customer entitlement data for troubleshooting while preventing it from updating account status directly.
• A security copilot reads audit logs and join tables to detect anomalous API key use, then hands off remediation to a separate privileged workflow.
• A data product exposes read-only access to reporting views rather than base tables, limiting what an NHI can see or infer.

This pattern is especially important when query templates are reused across environments. The same design issue appears in cases such as SAP SQL Anywhere Monitor Hardcoded Credentials, where operational convenience can mask excessive access. It also aligns with the broader identity and authorization expectations described in NIST Cybersecurity Framework 2.0 and in read access patterns discussed around service-to-service security in NHI programs.

Why It Matters in NHI Security

Read-only SQL is a practical guardrail against agent overreach. When an AI agent can query operational data, but cannot mutate it, the blast radius of prompt injection, tool misuse, and compromised credentials is reduced. That matters because NHI Management Group reports that 97% of NHIs carry excessive privileges, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. A read-only posture helps separate observation from action, which is a core Zero Trust principle.

It also reduces the chance that a reporting agent becomes an accidental operator. If a service account can only read, then a malicious prompt, malformed workflow, or bad model output cannot silently change records, revoke access, or create persistence. For teams designing agentic systems, this control should be paired with explicit write workflows, approval gates, and separate identities for execution. The underlying governance logic is consistent with NIST Cybersecurity Framework 2.0 and the hardening concerns raised in SAP SQL Anywhere Monitor Hardcoded Credentials.

Organisations typically encounter the need for true read-only SQL only after a model or service account has already altered data, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why do BI platforms become especially dangerous when authentication bypasses can be chained with file read, SQL injection, and deserialisation flaws?
• Why do read-only AI agents still create serious security risk?
• What breaks when AI coding agents can read project setup metadata?
• What breaks when an AI browser can read local files inside a user session?