Here is a story that is becoming common enough to be predictable.
A team connects an AI agent to their Boomi account using an existing admin login. It works immediately, which is the problem. Everything is available to it, every environment included. A few days later, while investigating why a run had failed, the agent adjusts a live production schedule. Nothing in its permissions had told it not to, because nothing in its permissions had told it anything at all.
That is not an AI failure. It is an access control failure, and it is one no organisation would tolerate from a human. Nobody hands a new starter full production rights on their first morning and hopes for the best. Yet AI agents routinely get exactly that, because connecting them is fast and scoping them is not.
The tools are already in Boomi to do this properly. Most teams simply have not been shown where they are.
What Boomi Companion Actually Is
Before scoping its access, it helps to be precise about what you are scoping.
Boomi Companion is an open-source suite of Agent Skills that lets you work with the Boomi Enterprise Platform in natural language. Each skill packages platform knowledge together with the tools and prompts an AI agent needs to act on it, so a plain-language request becomes real work in your Boomi account. Because it is built on the Agent Skills open standard, it is agent-agnostic, running inside coding agents such as Claude Code, OpenAI Codex, and Google Antigravity, as well as chat environments like Claude Cowork.
Underneath, it works through the Boomi Platform API, the same interface that has handled platform interactions for years. That detail is the whole story from a security standpoint. Companion is not a special back door and it has no privileges of its own. It performs the same actions through the API that a human performs through the web interface, which means its power is defined entirely by the account it authenticates as.
Give it an admin account and you have given it admin. Give it a scoped account and you have given it a job description.
One more thing worth knowing before it touches anything important. Boomi is explicit that Companion is a publicly available developer offering rather than an officially supported product. It is provided as-is, curated on a best-effort basis, and sits outside Boomi's standard support agreements and SLAs. That does not make it unsuitable for serious work, but it does mean the governance around it is your responsibility rather than something you can escalate.
Why the Permission Model Is the Whole Control
There is a temptation to think of AI safety here as a matter of prompting. Tell the agent not to touch production, and it will not touch production.
That is not a control. It is a request. Instructions in a prompt or a configuration file influence behaviour, they do not constrain it, and an agent working through an API with valid credentials for a privileged account can do whatever that account permits. The only reliable boundary is the one enforced by the platform itself.
This is the same lesson integration teams have already learned the hard way with ungoverned automation across other platforms, where the tooling changes but the governance requirement does not. An automation running with a personal admin credential, no documentation, and no oversight creates identical exposure whether a human built it or an agent did.
So the question is not how to instruct the agent. It is what the account it uses is actually allowed to do.
The Two-Role Model
The practical answer is that Companion needs genuine capability, just not everywhere. That splits cleanly into two roles.
Non-production: full access
In development and test environments, restricting the agent defeats the purpose. Let it build, edit, and test processes. Let it deploy to non-production environments. Let it manage runtimes. Let it view results, dashboards, and audit logs. This is where the productivity gain lives, and the blast radius of a mistake is a broken test, not a broken order flow.
Production: read-only
In production, the agent should be able to look and nothing else. Viewing processes and components, execution results and logs, and dashboards covers everything needed for diagnosis. Build, deploy, and configuration rights do not belong here.
This split matches how most people actually use an agent. You want it investigating a production failure and telling you what went wrong. You do not want it fixing that failure directly in production at two in the morning without a human in the loop.
What to withhold from both roles
Three privilege sets should stay out of both roles entirely: account administration, user management, and full environment management.
The reasoning is straightforward. An agent that can create users, alter roles, or reconfigure environments can grant itself more access than you intended. Those are precisely the privileges that turn a contained boundary into a suggestion. Whatever limits you set elsewhere depend on the agent being unable to change the limits.
Give it its own identity
Do not let the agent authenticate as a person. Create a dedicated service account for it.
This matters for a reason that only becomes obvious after an incident. If the agent shares a login with a human, your audit trail cannot distinguish between them. The question "who changed this and why" has no answer, and in a regulated environment that is a finding. A separate service account keeps attribution clean and lets you revoke the agent's access without disrupting anyone's day job.
Enforcing It at the Environment Level
Creating roles is necessary but not sufficient. Without environment-level access restrictions active, read-only in production describes an intention rather than a boundary.
In Boomi this is handled through Advanced Environment Access, found under Account Settings in the account features. Enabling it takes effect immediately. It forms part of Boomi's advanced security licensing, so if you cannot see the option in your account, confirm availability with your Boomi representative before planning around it.
One piece of advice that saves a bad afternoon: audit who currently holds broad environment access through other roles before you enable this. Tightening the agent's boundary can inadvertently restrict members of your own team who were relying on permissions they did not know were that wide. Find that out during planning rather than during a release.
There is also a small operational wrinkle worth anticipating. Boomi will not let you generate a platform API token on another account's behalf, so the service account has to sign in once itself to create its own token. That single login is the one moment the process requires a human, and it is worth doing deliberately.
The Credential Problem That Sits Underneath All of This
Roles govern what the agent may do. Credential handling governs what the agent can see, and it is the part most teams overlook.
Boomi Companion authenticates using a platform API token, with the username and token typically held in an environment file in the project workspace. Those values are sensitive, and the risk is not only that someone reads the file. Boomi's own engineering team has been candid that the most novel challenge they faced was preventing credentials from leaking into the AI context window, where they could be viewed, logged, or used in ways nobody intended.
Several protections ship by default. The plugin configuration blocks the agent's file-reading and shell tools from accessing environment files. Credential access is routed through scripts that load values into short-lived, limited-scope variables rather than exposing them to the agent directly. And when connector components are pulled down through the platform API, embedded credentials arrive encrypted rather than in plain text, which means connectors can be reused without their secrets ever reaching the agent.
That last point carries a practical recommendation. Configure connections in the Boomi web interface rather than through the agent. The agent can then reference them by component URL, getting the reuse benefit with none of the exposure. It is also a long-standing Boomi best practice independent of AI.
Where the defaults stop is worth stating plainly, because Boomi states it themselves. There is no practical way to stop a user deliberately pasting credentials into an agent session. If your risk profile demands more, the recognised hardening path is to replace local environment files with a proper secrets management and security engineering practice and to implement managed session logging. Neither is exotic. Both are the sort of thing that gets deferred until an audit asks.
Why This Is Worth Doing Now
The convenient assumption is that access can be tightened later, once the agent has proven useful.
In practice it does not happen. The configuration that works becomes the configuration that stays, because revisiting a working setup has no urgency attached to it and no obvious owner. The permissions you assign in the first week are, realistically, the permissions the agent keeps.
Agentic tooling is not a passing experiment in the integration space. Boomi Companion works across dozens of AI tools and ships free with a platform licence, which means adoption inside your Boomi environment may already be further along than you think. Someone may have connected it last month without a conversation about scope.
The setup described here takes an afternoon. Retrofitting governance onto an agent that has been operating with admin rights for six months, and reconstructing what it did during that time, takes considerably longer.
Conclusion
Boomi Companion is a genuine capability gain. It brings platform expertise into the tools your team already works in, and it does real work against your real account rather than producing suggestions.
That last part is exactly why the access model matters. Everything it can do is defined by the account it runs as, so the account is the control surface. Two scoped roles, full access in non-production and read-only in production, with account administration and user management withheld from both, a dedicated service account for clean attribution, environment-level enforcement so the boundary is real, and credential handling that keeps secrets out of the context window.
None of that is unique to AI. It is ordinary least-privilege discipline, applied to a new kind of user. The only genuinely new thing is that this user works faster than a human, which means a permissions gap gets exercised sooner.
Give it the access it needs to be useful. Withhold the access it needs to be dangerous.
