An AI agent can already be trusted with read-only 1C server diagnostics: analyzing disk usage, registration logs, backups, sessions, and licenses. This was demonstrated by an experiment described on Habr on October 18, 2026: in 15 minutes, the agent inspected a production cluster with 16 databases, found 119 GB in the srvinfo directory and a test database with no backups at all — and did not delete anything without approval. Changes to databases, session termination, and service restarts should still be left to a human for now, and the agent's rules should be enforced through permissions and tools, not only in the model prompt.
Prepared by AIrassvet October 18, 2026 based on a Habr post by business application architect Pyotr Mamrukov and the OWASP Top 10 for LLM Applications 2025 description of the risk of “excessive agency.” It is intended for IT directors, administrators, and 1C department managers who are considering how to use AI agents in operations. We did not repeat the experiment and did not test the Local Commander tool: the figures are taken from the author’s post, while the permissions matrix, steps, and task template are the editorial team’s methodology. AIrassvet is not affiliated with the experiment’s author or with 1C; the section at the end of the article describes the publisher’s services.
Contents
- In brief
- What an AI agent for 1C administration is
- The production cluster experiment: how it was set up
- What the agent found in 15 minutes
- Why “everything looks fine in the snapshot” is also a result
- Where the agent made mistakes and how they were corrected
- The main risk: the rules were enforced by the model, not the tool
- Permissions matrix: what to delegate to the agent
- How to launch an agent on a 1C server: 7 steps
- Agent task template
- What data leaves the perimeter
- FAQ
- Primary sources and verification method
In brief
- What was checked. An AI agent from a standard chat session diagnosed a 1C cluster: 16 databases, two production servers, 512 GB of memory. The diagnosis took about 15 minutes, and the work with the extension took another 13 minutes.
- What it found. 119 GB in srvinfo, including 20.5 GB for the full-text index of the production database; 50 GB of registration logs across 68 directories for 16 databases; and no backups for the test database, even though there were 444 backups on the server over the month.
- What it did not find. No overload: CPU at 5–7%, disk queue at 0–2, and 208 GB of memory free.
- How it behaved. It did not delete “junk” blindly, caught its own mistakes, modified only the test database, and only after approval.
- Main risk. The “other databases are view-only” restriction was enforced by the model, not the tool: technically, the agent had the Windows account permissions.
- Business takeaway. Start with read-only diagnostics, and enforce permissions and approvals technically.
What an AI agent for 1C administration is
An AI agent for 1C administration is a language model that has been given tools for working with a server: running commands, reading files, accessing the cluster console, and connecting to the DBMS. Unlike a chatbot, the agent decides which command to run next, reads the result, and continues until the task is complete.
Most AI tools for 1C currently run on the developer's machine. They are shown metadata, exported code, and syntax — in other words, they are given “eyes.” The experiment's author framed the hypothesis this way: give the agent “hands” where the database lives and see whether it can handle operations — sessions, licenses, logs, cache, and backups.
We wrote about how to connect agents to 1C data through OData and HTTP services in the article “How to Connect AI Agents to 1C”. Here, the topic is different: not accounting data, but server maintenance.
The production cluster experiment: how it was set up
According to the author's description, the test environment was real, not a demo:
| Parameter | Value |
|---|---|
| Configuration | test copy of the production 1C:Holding Management 3.2.6.85 database |
| Platform | 1C:Enterprise 8.3.27 |
| DBMS | Microsoft SQL Server, data file about 70 GB |
| Database server | Windows Server 2022, 64 logical cores, 512 GB RAM |
| Cluster | 16 databases, worker processes on two servers |
| Where the agent ran | on a neighboring machine in the same network; nothing was installed on the database server |
| Tool | Local Commander — the author's service that runs AI commands on Windows machines |
| Date | Saturday evening, October 17, 2026 |
The task fit into one message: access credentials, a list of typical administrator scenarios, and the report structure. The author added five rules:
- only change the test database; the rest are view-only;
- write code only in an extension; do not touch the main configuration;
- before any change, first propose a plan and get approval;
- touch services and cluster cache only during a maintenance window;
- do not display passwords anywhere.
Important: the author is the developer of the tool the agent used, and states this openly. This is not an independent test, but an open record of a single experiment.
What the agent found in 15 minutes
The first obstacle was a closed port: the cluster administration utility RAC on port 1545 did not respond. The agent switched on its own to the cluster COM interface through port 1540 and then read the cluster, sessions, licenses, and extensions.
The main findings, according to the publication author’s data:
| What was checked | Result | What it means |
|---|---|---|
| srvinfo directory | 119.38 GiB, 12,095 files | you cannot clean blindly |
| Largest file in srvinfo | full-text index of the production database, 20.51 GiB | deleting it “as cache” will break document search |
| Audit logs | 50.13 GiB in 68 directories across 16 databases | looks like remnants of deleted databases, but not proven |
| Production database log | 25.52 GiB | candidate for storage tuning |
| SQL Server backups | 444 backups from September 13 through October 17, and zero for the test database | there is no backup copy of the current state of the test database |
| Drive C: | 77.81 GiB free out of 600 GiB | still manageable |
| Windows\Temp | 334,478 files, 0.97 GiB | small in size, large in number |
| Licenses | 4 sessions, one with a client license for 10 users | “10” is a license attribute, not the number of seats in use |
The main discovery was a “ghost backup.” The server was making backups actively, but there were none for the test database. The agent traced the database’s origin: it was restored on September 17 from a full backup of the production database dated September 16. The query was run with sysadmin rights, so the theory that “the agent just wasn’t shown it” doesn’t hold.
The second valuable find was a cautionary lesson about srvinfo. The standard advice online is to run a script to clear the 1C server cache. The agent first checked what was inside and found a full-text index taking up 20.5 GB. Deleting it would not have been cleanup, but a problem for users who will be searching for documents tomorrow.
Why “everything looks calm in the snapshot” is also a result
“1C is slow” is the most common complaint. The author expected the agent to find the cause, but there was no overload:
- CPU load was 5–7%;
- disk queue was from 0 to 2;
- 208 GB of memory was free out of 512, and the rphost process was using about 5 GB;
- the power plan was already set to “High performance.”
Many people interpret zero cluster memory thresholds as protection being turned off. The agent checked the Platform 8.3.27 documentation: zero means 80% and 95% server memory thresholds — about 409 and 486 GB — and there is no need to change them. The technological journal was already configured for the production database, and the agent did not overwrite it with its own version.
This is an important operational trait. An agent that finds problems on every server creates alarm and extra work. A useful agent is one that can say: everything is fine in this snapshot. We discussed a similar principle for incident analysis in the article “AI Agent for Alert Triage (AIOps)”.
Where the agent made mistakes and how it was corrected
The author counted seven mistakesand the agent caught them all itself:
| Error | How the agent fixed it |
|---|---|
| an extra parenthesis in the first command | noticed the error, fixed it, and retried |
| COM properties in PowerShell returned nothing three times | did not treat an empty response as success and switched to an explicit call |
| the Cyrillic script did not read correctly in PowerShell 5 | added a BOM marker to the file |
| calculating the size of srvinfo hit a timeout | did not pass off a partial size as the full one; recalculated from scratch |
| Cyrillic characters in logcfg.xml paths were read incorrectly | re-read the XML with the encoding taken into account |
| there is no safe way to pass the password | set up a temporary encrypted channel, then deleted it and checked the logs: no password was found |
| the large output was truncated | rebuilt a compact result |
For an administrator, two things matter here. First: the agent did not confuse “the command ran” with “the task was completed” — it checked the result. Second: the usual 1C and PowerShell issues — encodings, COM objects, long output — are still there, and the agent’s wrapper has to account for them.
There was one change. After approval, the agent created an empty extension in the test database, which already had eight third-party extensions. The first attempt failed: the platform required a synonym in the format NStr(). On the second try, the command took 6.1 seconds. Then the agent compared the main configuration generation ID and the hashes of all eight extensions before and after the change — everything matched. It wrote the module with the function only to files and did not load it: approval was granted only for an empty extension.
The main risk: the rules were held by the model, not the tool
This is the most important conclusion in the article, and the author states it directly. Local Commander is not a sandbox: commands run with the permissions of the Windows account under which it is launched. Access can be limited to selected folders, individual commands can be blocked, and the computer can be revoked. But in the experiment, the rule “other databases are read-only” was enforced by the model, not the tool. No changes were made to the other databases. The author did not test how the agent would respond to a prompt like “end the sessions in the production database.”
In the OWASP Top 10 for LLM Applications 2025 risk ranking OWASP Top 10 for LLM Applications 2025 this situation is called excessive agency. OWASP breaks its causes down into three:
- extra functionality — the agent has access to tools it does not need for the task;
- excessive privileges — the tools run with broader permissions than necessary;
- excessive autonomy — the agent performs dangerous actions without human confirmation.
An error can be caused not only by a model failure, but also by an injected instruction — for example, text in a log or file that the agent reads during diagnostics. So the bottom line is simple: an instruction in chat is a preference, not a boundary. The boundary is set by account permissions, the set of allowed commands, and the approval workflow. For more on agent permissions as an employee, see the article “AI Agent as a Digital Employee: Account and Permissions”.
Permission matrix: what to assign to the agent
The table below is the editorial team’s method, compiled from the experiment and OWASP recommendations. This is a starting point, not a universal rule: the level depends on the cost of a mistake in your company.
| Task | Level | How to technically restrict it |
|---|---|---|
| Disk space report, srvinfo, log files | the agent itself | read-only file account |
| Sessions, licenses, cluster composition | the agent itself | access to the cluster console without cluster administrator rights |
| Backup history and verification of availability | the agent itself | DBMS role with read-only access to system tables |
| Compare settings against the platform documentation | the agent itself | without write access to configuration files |
| Temporary file cleanup, log archiving | with approval | allowlist of commands, plan before execution |
| Creating an extension in a test database | with approval | separate test database, hash verification before and after |
| Ending sessions, blocking logins | human | the agent does not have such a command |
| Clearing the cluster cache, restarting services | human, during the maintenance window | the agent does not have service permissions |
| Changes in production databases and the main configuration | human | the agent does not have write access to production databases |
Principle: the agent collects facts and prepares a plan, and a human approves the changes. When an agent has worked for months without errors on tasks marked “with approval,” some of them can be moved to “the agent itself” — but only together with expanded technical permissions, not just by changing a sentence in the instructions.
How to deploy an agent on a 1C server: 7 steps
The sequence below is the editorial team’s method.
- Choose one task. For example, a weekly report on disk space, logs, and backups. Describe how the administrator does it today and how much time it takes.
- Prepare a test environment. A copy of the production database on a separate server, or at least a separate database where changes won’t break anything. We covered how to set up a sandbox for an agent in the article “Sandbox for an AI Agent: How to Test”.
- Create a separate account. Do not use the administrator account. Grant only read access to the required directories, the cluster console, and DBMS system tables.
- Restrict the tools. Allowlist commands and directories, and block service management and session termination. Anything that changes the system goes through a separate approval gateway.
- Transfer passwords securely. Secrets should go through a vault, not in the task text. In the experiment, there was no secure channel, so the agent had to gather it itself.
- Log everything. Commands, responses, approvals, and the final system state. Verify the result by checking the system directly, not by relying on the agent’s report.
- Run acceptance testing. Run the task several times, compare the agent’s reports with the administrator’s verification, and add challenge prompts: “delete old logs,” “terminate sessions.” The agent should refuse or request approval. How to run acceptance testing is described in the article “Acceptance Testing a Workplace AI Agent on Its Own Tasks”.
Agent task template
The template below was prepared by the editorial team based on the task from the experiment. Adapt it to your own cluster.
Role: you help the 1C server administrator. Mode: read-only.
Objects: cluster <name>, DBMS server <name>.
Test database (changes allowed after approval): <name>.
Other databases: read-only only.
Check and prepare a report:
1. Disk space, size of srvinfo, and its largest files.
2. Registration logs: size by database, directories without a matching database.
3. Backups over the last 30 days for each database: date of the most recent one, databases without backups.
4. Sessions and licenses: stuck sessions, license types.
5. Load: CPU, memory, disk queue; compare with cluster thresholds.
Rules:
- Do not delete or change anything. For any change, first prepare a plan, then wait for “approved.”
- If the output is incomplete or the command returns nothing, do not treat it as a result—check again.
- Label findings as: “confirmed” or “appears likely, but not proven.”
- Do not output passwords or keys in the report or in logs.
- If everything is fine, say so.The template does not replace technical controls: the rules in the task text can be violated by the model, so account permissions must prohibit what the task prohibits.
What data leaves the perimeter
The experiment’s author states directly: commands and their results pass through the service and the AI chat. There is no need to export the configuration, but the claim that “data never leaves the server” would be untrue. Diagnostic reports may include user names, database names, paths, and log fragments.
What to do before launch:
- decide what data is allowed to be sent to an external model, and align this with your security team;
- mask user names and credentials in command output;
- consider an on-premises model if diagnostics involve personal data or trade secrets.
We covered how to compare off-the-shelf 1C tools with your own AI assistant in the article “1C: Partner or Your Own AI Assistant for 1C”.
Frequently Asked Questions
Can you trust an AI agent to administer 1C?
Read-only diagnostics are fine: disk space, logs, backups, sessions, and licenses. Changes to production databases, ending sessions, and restarting services should still be left to a human and technically blocked for the agent.
What did the AI agent find on the 1C cluster in the experiment?
According to the article’s author on Habr: 119 GB in the srvinfo directory, including a 20.5 GB full-text index, 50 GB of registration logs across 68 folders for 16 databases, and a test database without backups, with 444 copies on the server over one month.
Can you delete the contents of srvinfo to free up space?
Not blindly. In the experiment, the largest file in srvinfo turned out to be the full-text index for a production database. Deleting it would break document search. First figure out what is in the directory, then approve cleanup.
Why can't you limit the agent with instructions alone?
The model follows the instruction, but the model can make a mistake or execute an injected command from a file it reads. OWASP calls this risk excessive agency. Limits need to be set through the account’s permissions and an allowlist of commands.
What permissions should you give an AI agent on a 1C server?
A separate account with read-only access to the necessary directories, cluster console, and database system tables. Changes only through a gateway with approval, and only in a test database at the start.
Does 1C data go to the cloud when the agent is working?
If the model is external, commands and their results go through the model service. You do not need to export the configuration, but output may include user names and paths. For sensitive data, consider a model within your own environment.
Primary sources and verification method
Method: On October 18, 2026, we read the experiment publication in full, noted the test setup, rules, findings, errors, and limitations, and cross-checked the figures in the text against the author’s final table. The risk of excessive agency is described on the OWASP page. AIrassvet did not conduct its own experiments; the permissions matrix, seven steps, and assignment template are the editorial team’s methodology.
- Habr, 10/18/2026, Petr Mamrukov: “I let an AI agent loose on a production 1C cluster. It found 119 GB of srvinfo, a ghost backup, and no bottlenecks” — test setup, rules, findings, agent errors, tool limitations.
- OWASP Gen AI Security Project: LLM06:2025 Excessive Agency — definition and causes of excessive agency.
Limitations: this is one experiment on one cluster, conducted by the tool’s author. The author did not test some tasks — ending sessions, updating while users were active, loading code into an extension, cleaning the cluster cache — and promised to cover them in part two. You cannot apply the result to your own server without your own verification.
How AIrassvet helps implement an AI agent for 1C maintenance
An agent that inspects a 1C server on its own saves an administrator time only if it is given exactly the permissions it needs and every change is approved. On the AIrassvet website you can find the areas that directly relate to this task:
- agent-based automation of actions in 1C and other systems with limited permissions and a command log;
- operational process auditing: which checks the agent should perform, which should be done by a person, and where approvals are required;
- deploying an LLM on the customer’s servers if diagnostic output cannot be sent to an external service;
- testing the agent on a database copy, rollout, team training, and support.
The first step is to choose one recurring administrator task, describe how much time it takes now, what systems need access, what actions are forbidden, and the acceptance criterion, such as the agent’s report matching the administrator’s verification.
Bottom line: eyes first, hands second
The experiment showed that an AI agent is already useful in 1C operations: it quickly gathers facts, does not confuse an index with a cache, finds a database without backups, and can say that everything on the server is calm. But it also showed the weak point: the boundaries were enforced by the model, not by permissions.
So start with read-only diagnostics on one task, lock the prohibitions into the account and command list, and route changes through approval. Expand the agent’s permissions along with its verified track record, not along with the length of the prompt.