AI Agent Security
CustomerNode did not start with agents. It started as one secure platform for complex B2B sales: every customer's data isolated at the application layer, and a content-locking model so no two people ever collide on the same edit. The agents came later, and they were built to work inside that place, on behalf of the people already in it. Security here is not a governance policy wrapped around an agent. It is the ground the agent stands on.
Turn the key
Most enterprise AI is something you build. You pick a model, wire it to your data, stand up the tools, add the dashboards, and hold the whole assembly together yourself. Every seam you add is a seam someone has to secure.
CustomerNode is the environment, not the parts. Agents, collaboration spaces, and dashboards ship together, already connected, already inside the same governed boundary. You turn the key and build on top of it, in a safe and managed space, instead of building the space first and defending it later.
And that environment was secure long before it had agents. The hard problem in collaborative B2B sales was never AI. It was letting your team, your customer's team, and their guests all work inside the same journey without one customer's data leaking into another's, and without anyone overwriting anyone else. CustomerNode solved both first: tenant isolation enforced at the application layer, and a modular content-locking model for concurrent editing. The agents were placed inside that. They were not bolted on top.
Agents are scoped by access
Inside a tenant, an agent's power is set by its access scope. The scope is fixed up front, and it sets both what the agent can see and what it can do. The pattern is deliberate: the wider an agent's view, the less it can change; the more an agent can change, the narrower its scope.
The widest view. They read across the journeys in your tenant to surface patterns and generate insight, and they carry no write capability at all. Broad sight, no hands.
The same read-only insight capability, scoped to a single journey. This is how a customer or a guest on a journey gets insight generation bounded to their journey and nothing beyond it.
Scoped to a single stage, with a job to match: assigning owners on a deploy stage, running a smart conversation on a discovery stage. An agent that can act can only write to the one stage it is attached to, never to the rest of the journey, let alone another tenant.
How an agent acts, and what it leaves behind
Even within its scope, an agent never executes a command directly. It proposes; a deterministic runner disposes. The agent produces a structured proposal, never a raw action, and on a stage that proposal takes effect only when a person accepts it. A human is in the loop before anything changes.
When an agent does act, it works inside the same real-time collaboration model as your people. It cannot quietly overwrite work a colleague has open, any more than one teammate can overwrite another. Collaborative editing without collision is a problem CustomerNode solved for human teams years ago, and agents live inside that same model.
And everything an agent does lands in the same audit history as a person's actions, attributed to the user who invoked it and flagged as AI. A customer administrator can review exactly what an agent did, when, and on whose behalf, in the same place they review everyone else's activity.
No rogue agent
Security teams share a model for when an AI agent turns dangerous: when four properties overlap. Unreliable reasoning, high agency, sensitive data access, and privileged system access. In CustomerNode the overlap has nowhere to form.
- Sensitive data access is bounded by the tenant boundary, checked before any data is loaded and again before the model is called. No agent, at any scope, has a door through it.
- High agency is bounded by the access scope. Agents with a broad view can only read; the agents that can act see only one stage.
- Privileged execution has no path to exist. An agent can propose changes but never runs commands; the system carries out only its own defined actions, under the user's permissions, so there is nothing to hijack.
- Unreliable reasoning is the one property you cannot remove, so it is insulated. A wrong output is caught by the boundary, the scope, and the proposal check before it reaches anything that matters.
When the input is hostile
Some of what an agent reads is hostile by nature. Agents summarize web pages and uploaded files, which an attacker can control. That is prompt injection, and here it has nowhere to go. Whatever the model produces is still only a proposal, a person still has to accept it, and the agent is still bounded to one stage under the user's permissions. The worst a successful injection can do is propose a bad edit that a human then rejects. It cannot widen the agent's scope, write outside its stage, or reach another tenant.
Two controls we intentionally do not perform
Two controls a security review may ask about are out of scope for CustomerNode by design. We answer them the same way every time.
- Model scanning. We do not host or fine-tune shared foundation models, so there is no foundation model of ours to scan. We call OpenAI and Anthropic as subprocessors, configured so customer data does not train shared models, and we treat every model output as untrusted regardless, turning it into a checked proposal before anything acts on it.
- MCP server scanning. We do not operate an external MCP registry, and our agents do not reach out to a fleet of external tool servers, so there is no external tool-server surface for us to scan.
None of this is a marketing claim. Each control is written down, enforced, and tested against cross-tenant access. Agents are held to the same permissions as the user who invokes them, so a broad insight agent can never surface a journey the person could not open themselves. We are glad to walk your security team through exactly how any of it works under review.
For the rest of a security review, this page sits alongside our General Security (encryption, SSO and MFA, SOC 2 Type I, logging, backups), AI Governance and GenAI Governance Policy (tenant AI disablement, no shared-model training, OWASP LLM Top 10 vendor assessments), Subprocessors (the AI providers we use, each tenant-disablable), Privacy and the Data Processing Addendum (retention, deletion, breach notification), the Audit Policy, and our Vulnerability Disclosure Program. What you read here is what you can hold us to; the architecture is patent-pending, with the full detail in the CustomerNode Insights series.