When customers come to us with AI agents already running in their environment, the conversation is never about whether to allow them. That decision has already been made. Engineers are running coding agents, executives are experimenting with productivity tools, and in most cases, security learns about it through an IT ticket rather than a formal risk review. The question our customer success team hears in week one is: "AI agents are running in our environment. What do we do now?"
The core issue is that nobody can answer a basic audit question: what did that session actually do? The customers we onboard across financial services, healthcare, and technology want the productivity these tools deliver. They also have to sign off on the quarterly risk review.
This post covers four operational controls that close that gap. We have walked every customer through this sequence during onboarding. Each guardrail deploys in a week. None requires a six-month program.
What We See in Week One
When we onboard a new customer who already has AI agents running in their environment, four issues come up in nearly every conversation.
- "Can our engineers use AI agents in production codebases without leaking sensitive context?" A session connected to a Jira MCP server, a GitHub integration, and a database connection has a broad blast radius. The developer did not configure it that way intentionally; they connected the tools they use every day.
- "How do we prevent an agent-generated tool call from making destructive changes to production?" This comes up most with DevOps and platform teams who have seen what happens when an agent makes an assumption about what "clean up" means.
- "How do we know what the session actually did?" EDR shows process activity on the endpoint. It does not show the prompt that was sent, the tool call that was made, or the file that was written.
- "If one of our developers installs a malicious instruction set or connects to a compromised MCP server, what does that expose?" Every agent configuration file is code. Every connected MCP server is a vector.
The customers who come out of onboarding in a strong position have answered all four before opening any agent platform to broad developer access. Here is the sequence we use.
Four Operational Guardrails
1. Build the AI Inventory First
You cannot govern what you have not found. The first thing we do in every onboarding is run discovery across the managed endpoint fleet to surface every agent installation, every active instruction set, and every connected MCP server. That inventory is the baseline for everything that follows.
Discovery deploys via Intune, Jamf, or CrowdStrike RTR in under an hour. What it surfaces in the first 24 hours is usually more than the security team expected: integrations IT never reviewed, agent runtimes on outdated versions, and community-sourced instruction packages from registries nobody has audited.
The same inventory logic applies across every agent runtime in the environment, whether a team is using a commercial coding agent, a self-built orchestration layer, or a third-party platform. The question is not which runtime a team is using. It is whether the security program can see it.
Anything not in the inventory is operating outside the security program. The frame we use with every security architect in week one is not "is this agent risky?" but "how much of your agent deployment is currently visible to security?"
2. Scan Agent Configurations Before They Execute
Every agent configuration is code. Treat it that way.
The instruction sets, rules, and workflow definitions your developers load into their agent runtimes define behavior. A configuration that fetches content from an untrusted external URL, stores credentials in plaintext, or uses overly broad tool permissions is a risk that exists before the model runs a single prompt. Posture scanning catches it before execution.
The risk surface we look for in configuration reviews:
- Hardcoded secrets or API keys in instruction files or rule definitions
- Untrusted content fetching from external URLs at runtime without validation
- Insecure credential handling in MCP server configurations
- Overly permissive tool access defined in agent rules
Configuration scanning gives the security team a posture view of the agent configuration layer before any enforcement decision is made. The question shifts from "is this configuration trustworthy?" to "here is the posture score and the specific risk factors driving it."
3. Monitor the Agent Session, Not Just the Endpoint
EDR covers the box. It does not cover the session.
The audit question from the opening of this post is only answerable if you are capturing session-level data: the prompt that was sent, the tool calls that were made, the model responses, the files written or read. Your EDR will tell you a process ran. It will not tell you the agent wrote a file containing sensitive data because a prompt was injected through a Jira ticket description.
Session-level capture surfaces the full interaction record per session, correlated to user identity and device. That is the record the security team reviews the next morning and what legal requires when an incident is raised.
The posture scan tells you about configuration risk. The session record tells you what happened at runtime. Neither substitutes for the other. This pattern holds across every agent runtime we see in customer environments: Cursor, Claude Code, self-built stacks, and commercial tools alike.
4. Enforce Policy at the Tool-Call Boundary
Detection is necessary. Enforcement is the control.
AI Guard sits inline between the agent and its tool calls. The security team can block destructive operations before they execute, mask sensitive data in both directions, and apply just-in-time access scoping so a session authorized for database reads does not carry standing write access.
Three controls we activate in every onboarding engagement:
- Destructive action blocking. An agent session that attempts a file delete, a database write outside its scope, or a shell command outside approved policy: AI Guard blocks the tool call before it executes and logs the attempt.
- Sensitive data masking inline. PII, credentials, and confidential content detected in prompt or response are masked in transit. The developer experience is preserved; the data exposure is not.
- Tool restriction by policy. Natural-language rules scoped to specific agents or user groups. The security team writes the policy in plain language; enforcement is automatic across current and future sessions.
This enforcement layer operates at the boundary that matters: the moment the agent calls a tool. Whether the runtime is a commercial product or a self-built orchestration layer, the tool call is the common control surface.
The Onboarding Sequence That Works
We have converged on a week-one structure that gives every customer meaningful coverage by day ten.
Days 1-3: Deploy discovery and build inventory. Run discovery across the target developer cohort via Intune, Jamf, or CrowdStrike RTR. Document every agent installation, every active instruction set, and every connected MCP server. Flag anything outside managed endpoint coverage.
Days 4-7: Scan posture and prioritize risk. Run configuration scanning against the inventory. Score each configuration by risk factor. Identify the highest-priority findings: configurations with hardcoded secrets, MCP server connections the security team has not reviewed, agent runtimes on outdated versions. Decide what to allow, block, or flag with data in hand, before any enforcement change.
Week two: Enable session capture and enforcement. Connect AI Guard to the agent inventory. Enable session-level capture for the developer cohort. Start with alert-only on destructive action and sensitive data categories to calibrate the baseline before moving to blocking. Review the first week of session data. Harden the policy from there.
Inventory on day one. Posture data by end of week one. Runtime visibility by end of week two.
The Path That Holds Up
Customers who tried to ban AI agents outright are still having that conversation a year later. The install base grew faster than the ban could enforce. We see this pattern across every runtime category: the tools went in through developer adoption, not IT procurement, and a policy decision that came later had no teeth against endpoints that were already running.
Customers who allowed agents without guardrails are the ones managing the incidents.
Customers who are in a good position run this sequence: Inventory before policy, Configuration scanning before it became a supply chain problem. Session capture before they needed the forensics. Tool-call enforcement before a destructive action happened.
That is the operational pattern any platform claiming to secure AI agents has to deliver. Onyx is built to be that Secure AI Control Plane across the agent layer, whether that layer is a single runtime or a mixed environment of commercial tools and custom builds. The week-one sequence above is how you verify it works in your environment.
If your security team is working through the agent governance question right now, schedule a custom Onyx demo today.
