AI Security Controls

Last updated: June 2026

Vicaro lets organizations deploy autonomous AI agents - “AI employees” - that read messages, use tools, call third-party systems, run code, and act on a customer's behalf. This page describes the controls and configurations available to keep that usage governed, contained, and accountable.

Our approach is built on transparency and control. We ship secure, sensible defaults so that every organization is protected from day one - but we believe each organization is the right owner of its own security posture. So rather than make those decisions opaque, we give customers clear visibility into what their agents can do and the tools to define, tighten, and enforce their own security policy. You are never locked into our defaults; you can inspect them, adjust them, and replace them with rules that match your organization's risk tolerance. In short: Vicaro provides the information and the tooling; the customer enforces the security policy that fits their organization.

Controls marked ALWAYS ACTIVE are enforced for every customer and cannot be turned off. Controls marked CONFIGURABLE are available to every customer and are tuned per organization or per agent. This summary is intentionally control-level; implementation specifics are shared under NDA during security review.

Controls at a glance

A. Governing what agents do

These controls decide which actions an agent is allowed to take, and insert human judgment where it matters. They are layered: a customer-defined policy engine on top, sensible guardrails underneath, and an always-available stop at any time.

A1. Governance policy engine CONFIGURABLE

Every action an agent attempts - and every inbound message it receives - is evaluated against a customer-defined policy before it is allowed to proceed. Each policy carries one of four outcomes:

• Deny - the action is blocked before it runs, or its result is withheld from the model.
• Ask - the action pauses for explicit human approval (see A3).
• Warn - a pre-action warning holds the action until the agent acknowledges a stated caution; in other cases the caution is surfaced as guidance.
• Allow - the action proceeds.

Policies operate at two levels. Organization-level policies are set centrally and apply to every agent in the organization - a single place to enforce company-wide rules. Agent-level policies add controls specific to an individual agent. The two layers combine, and an organization-level deny always wins over an agent-level allow, so an organization-wide restriction cannot be loosened from within a single agent.

Across both levels, policies are evaluated in a strict precedence order - Deny over Ask over Warn over Allow - so a restriction always wins over a permission. Policies can govern who may interact with an agent, which tools and integrations it may use, what data may leave the organization, and how it handles specific categories of requests. The before-action gate is fail-closed: if the policy layer is ever unavailable, sensitive actions are denied rather than allowed through.

A2. Default guardrails & presets ALWAYS ACTIVE

Every organization starts with a baseline set of guardrails active out of the box, including:

• Only an agent's designated manager (or an org admin/owner) may connect integrations or add new tools to it.
• Only a manager/admin/owner may change an agent's governance policies.
• Requests originating from people who are not the agent's manager are treated with added caution, and unmanaged write actions to external systems are held pending acknowledgement.
• Tool and integration endpoints are required to use encrypted (HTTPS) connections; plaintext endpoints are blocked (local-loopback addresses excepted).

Additional one-click presets - such as a personal-data double-check before external communications - are available for customers to enable. Baseline guardrails can be tuned to an organization's needs.

A3. Human-in-the-loop approvals CONFIGURABLE

When a policy resolves to Ask, the agent pauses the action and requests approval from its designated manager before continuing. The manager can approve the action once, grant a time-limited allowance, permanently allow that action going forward, or deny it - all from the approval prompt. The action stays blocked until a decision is made or the request expires. Approval links and tokens are signed and never exposed to the AI model.

Agents can additionally run in a strict mode, in which any action without a matching allow policy is automatically escalated to human approval - a default-deny posture for high-sensitivity deployments.

A4. Kill switch ALWAYS ACTIVE

A running agent can be stopped instantly. Sending “stop” in the conversation immediately aborts the agent's in-progress run - halting any tools or actions still in flight - and the agent confirms that it has stopped. The command works no matter where the run is executing, giving anyone in the conversation a simple, always-available way to halt an agent the moment something looks wrong. This control cannot be turned off.

A5. Prompt-injection protection CONFIGURABLE

Agents that ingest untrusted content - inbound messages, web pages, tool output, forwarded data - are exposed to prompt-injection and indirect-injection attacks. Vicaro can score incoming content and tool results with a dedicated prompt-injection classifier and feed that signal into the policy engine, so customers can warn on, block, or require approval for content that appears to be an injection attempt. Scanning covers inbound messages, content-bearing tool output, and data an agent is about to forward into another system.

B. Controlling reach & spend

These controls bound who can engage an agent and how much it can do, so an agent's exposure and cost stay within limits the customer sets.

B1. Communication access controls CONFIGURABLE

Customers control who may interact with each agent and where. Access can be scoped independently for internal versus external channels and direct messages, ranging from disabled, to manager-only, to organization members, to anyone. An access whitelist further restricts the specific people or channels permitted to reach an agent. These controls are enforced authoritatively at the channel boundary, where inbound messages from parties outside an agent's permitted scope are dropped before the agent processes them.

B2. Spend & rate limits CONFIGURABLE

To bound the operational and financial blast radius of an autonomous agent, customers can set hard spend caps per agent and per scheduled task over a chosen period (daily, weekly, or monthly). When a cap is reached, the agent stops acting; for scheduled-task caps, the manager is notified. Agent execution loops are bounded to prevent runaway behavior, and an organization-level solvency check provides a final backstop on all activity.

C. AI supply chain & data protection

These controls govern which AI providers and models an organization's agents may use, and protect the data those agents handle - how it is encrypted and how activity is recorded.

C1. AI provider & model control CONFIGURABLE

Customers have full control over which AI providers and models are used within their organization. Vicaro is multi-vendor, and every agent's model is configurable per capability tier - the primary reasoning model, a lighter model for routine work, a more advanced model for harder tasks, and the embedding model can each be set independently and pinned to a specific provider and model.

At the organization level, customers can govern which model vendors are permittedand disable any they do not wish to use; an agent cannot be configured to use a vendor the organization has disabled. This lets an organization standardize on approved providers - for example, restricting agents to a single vendor, or to models that meet its data-handling requirements - across every agent it runs.

C2. Bring your own LLM key (BYOK) CONFIGURABLE

Customers may supply their own credentials for any supported model provider, at the organization or individual-agent level, so that inference runs under the customer's own provider account and commercial terms - data flows directly between the customer's own account and the model provider. Provider credentials are encrypted at rest and are never returned in plaintext through the product - only a short, non-reversible hint is shown for identification.

C3. Encryption ALWAYS ACTIVE

Sensitive data at rest - including provider keys, agent and system secrets, integration credentials, and OAuth tokens - is encrypted using authenticated AES-256 encryption. All data in transit is protected with TLS. For dedicated deployments (see D1), encryption can be rooted in a key owned and controlled by the customer.

C4. Audit logging ALWAYS ACTIVE

Agent and capability changes, governance and policy edits, credential and API-key operations, member role changes, refused requests, AI agents' actions outside Vicaro, and every action or view by Vicaro staff are recorded to an organization-scoped audit log. Each entry names the acting identity, whom it acted for, and the policy decision behind it. The log is append-only and hash-chained, with hourly checkpoints signed by a key held in a hardware-backed key service, so any altered or missing entry is detectable, and customers can verify an export independently. Older entries are archived to write-once storage for the customer's chosen retention, with legal hold. The log can be exported or streamed to the customer's SIEM. Audit access itself is a permissioned capability.

D. Deployment isolation

D1. Dedicated & in-cloud deployment (BYOC) CONFIGURABLE

For organizations with strict data-residency or isolation requirements, Vicaro can be deployed as a dedicated data plane inside the customer's own cloud account. In this model the customer's data - database, vector store, and secrets - remains in their environment and region of choice, behind private networking with default-deny network policies. Application encryption keys are generated inside the customer's own cluster and never transit Vicaro, and per-tenant access is independently isolated and revocable. Data residency can be pinned to the customer's required region.

This page focuses on controls specific to AI agents. Platform-level security - identity and access management, role-based permissions, organization and tenant data isolation, and related measures - is covered in our Security Measures. For the services we engage to process customer data, our authorized subprocessors list is available upon request. Security questions or a detailed review request? Contact us at security@vicaro.ai.