ERP AI Agent Read-Only SQL Server Role Generator
An AI agent should never connect to your ERP database with a powerful account. This generator writes the T-SQL for a dedicated login, a read-only role, column-level denies and a row filter so the agent can only see what its job requires.
Fill in
1. Login, user and role (run in master, then in the ERP database)
-- In master CREATE LOGIN [svc_ai_agent_ro] WITH PASSWORD = N'REPLACE_WITH_LONG_RANDOM_SECRET', CHECK_POLICY = ON, CHECK_EXPIRATION = OFF, DEFAULT_DATABASE = [ERP_PROD]; GO USE [ERP_PROD]; GO CREATE USER [svc_ai_agent_ro] FOR LOGIN [svc_ai_agent_ro]; CREATE ROLE [ai_agent_readonly]; ALTER ROLE [ai_agent_readonly] ADD MEMBER [svc_ai_agent_ro]; GO
2. Grants and explicit denies
GRANT SELECT ON OBJECT::dbo.item_mst TO [ai_agent_readonly]; GRANT SELECT ON OBJECT::dbo.po_mst TO [ai_agent_readonly]; -- Hide sensitive columns even though the table is readable DENY SELECT ON OBJECT::dbo.po_mst (vend_bank_acct, contact_email) TO [ai_agent_readonly]; -- Belt and braces: no writes, no execution, no schema changes DENY INSERT, UPDATE, DELETE, EXECUTE, ALTER ON SCHEMA::dbo TO [ai_agent_readonly]; GO
3. Row-level security by site
CREATE SCHEMA Security; GO CREATE FUNCTION Security.fn_site_filter(@site AS nvarchar(30)) RETURNS TABLE WITH SCHEMABINDING AS RETURN SELECT 1 AS allowed WHERE IS_MEMBER(N'ai_agent_readonly') = 0 OR @site = N'PLANT1'; GO CREATE SECURITY POLICY Security.ai_site_policy ADD FILTER PREDICATE Security.fn_site_filter(site_ref) ON dbo.po_mst WITH (STATE = ON); GO
4. Verify as the agent login
EXECUTE AS USER = N'svc_ai_agent_ro'; SELECT TOP (5) * FROM dbo.item_mst; -- Expect a permission error on denied columns and on writes: -- SELECT vend_bank_acct, contact_email FROM dbo.po_mst; -- UPDATE dbo.item_mst SET 1 = 1; REVERT; SELECT permission_name, state_desc, OBJECT_NAME(major_id) AS obj FROM sys.database_permissions WHERE grantee_principal_id = USER_ID(N'ai_agent_readonly');
Table and column names shown are examples; replace them with your ERP schema. Test on a non-production copy first. Row-level security needs SQL Server 2016 or later, and the filter column type in the function must match the table column. Rotate the password and store it in a secrets manager. Add database audit if your policy requires reads to be logged.
Agent access design review
An optional review of the roles, views and logging your AI agent should use.
Optional. The tool and every export work without this. No spam.
How to use it
Replace the table and column names with real objects from your ERP, preferably views that already expose only reporting fields. Run block one in master and the ERP database, grant only the objects the agent needs in block two, add the optional row filter in block three, and then run the verification block as the agent. If a write succeeds, stop and review the grants before connecting any AI tooling.
Why layers matter
A prompt that says do not modify data is not a control, because a model can be manipulated by hostile text in a record. The database enforces the limit instead. Grants define what can be read, column denies protect bank details and personal data, and row-level security keeps an agent for one plant away from another plant. A read-only agent also limits blast radius if a tool is misused.
- Grant on views, not base tables, where possible
- Deny sensitive columns explicitly
- Filter rows by site or company
- Log reads where policy demands it
Common mistakes
Adding the login to db_datareader gives access to every table, including payroll or banking data. Reusing the ERP application account bypasses your own role design. Forgetting to test as the login hides gaps. Some ERP vendors do not support direct database changes or objects in their schema, so confirm with the vendor and keep your objects in a separate schema.
Frequently Asked Questions
Should the agent query base tables or views?
Views are safer. They let you expose only the columns and rows the agent needs and keep it working when the base schema changes. Grant select on the views and nothing else.
Does DENY override GRANT?
Yes, in SQL Server a DENY takes precedence over a GRANT, which is why a column-level DENY works even when the table is otherwise readable by the role.
Will this affect ERP upgrades?
Possibly. Security policies with schema binding can block certain schema changes on the filtered table. Test with your vendor upgrade process, or prefer filtering inside a view.
Does this work for Oracle or PostgreSQL ERPs?
The pattern is the same (dedicated user, read-only role, column and row controls) but the syntax differs. This generator produces T-SQL only.
Netray builds read-only ERP agents that show the query they ran and respect your roles. We can review the database account design for your system.
Related Tools
Text-to-SQL Guardrails Checklist for ERP Data
Check that an LLM that writes SQL over your ERP is limited by database permissions, query validation, cost limits and audit trails.
Compliance & ContractsAI Data Classification Handling Matrix Worksheet
Decide per data class whether it may be sent to a hosted LLM, an on-prem model or no model, and who approves exceptions.
Developer ToolsvLLM Docker Compose Generator for a Private ERP LLM
Fill in the model, context length and GPU count to get a docker-compose file that serves an OpenAI-compatible endpoint inside your network.
Compliance & ContractsNIST AI RMF Core Functions Reference for ERP AI
See what the four NIST AI RMF functions ask for and what each looks like for an ERP assistant or agent.
More Developer Tools tools
See all- SAP Sales Order ABAP SELECT Generator (VBAK, VBAP, VBFA)
- SAP Sales Order Create BAPI ABAP Generator (BAPI_SALESORDER_CREATEFROMDAT2)
- SAP ABAP Open Items SELECT Generator
- SAP ACDOCA SQL Query Generator
- SAP QM Inspection Lot ABAP SELECT Generator
- SAP Quality Notification Pareto SQL Query Generator
- SAP QM Usage Decision BAPI Skeleton
- ABAP Custom Exception Class Generator
- ABAP Unit Test Class Generator