Vediram Cloud

Activate devices with a provisioning key, sign users in, sync policy and plugins from the Vediram Portal, and optionally forward audit events

Vediram Cloud lets you set Levee's rules once in the Vediram Portal and have every computer follow them. Connecting is optional. Without it, Levee works fully from a local policy.json and the local audit log. See Planning a deployment to choose.

Connecting gives you:

• Central policy. Author rules once in the Vediram Portal. Every signed-in Levee app picks them up.
• Device activation. Each machine registers with your tenant, so you can see active devices.
• Plugins (preview). MCP plugins your organization enables in its policy reach every activated device. See Plugins.
• Optional audit forwarding. Send audit events to the cloud for a central view in the Portal.

How do the pieces fit together?

There are two separate connections: the computer activates with your tenant's key, and each person signs in with their own account. The computer connection is set up once by IT. The user connection is what brings each person's policy to the machine.

A device without a provisioning key runs in local-audit-only mode: projects, policy, and the local audit log all work normally, but the device does not register with your tenant and never forwards audit events.

Step 1: Create a provisioning key

You need the administrator role in your Vediram tenant.

1. Sign in to the Vediram Portal.
2. Open Settings and go to API Keys.
3. Optionally enter a Label (for example Levee workstations) and generate a key.
4. Copy the key immediately. It starts with vdm_ and is shown only once: "copy it now, it will not be shown again".

One key can activate many devices. Create separate keys for separate rollouts if you want to be able to rotate them independently.

Step 2: Deploy tenant-config.json

Place the key on each machine in %ProgramData%\Vediram\Levee\tenant-config.json:

{ "apiKey": "vdm_0123456789abcdef0123456789abcdef" }

This file holds a secret. Restrict it to SYSTEM and Administrators, then restart the Levee service so it activates:

$tenant = "$env:ProgramData\Vediram\Levee\tenant-config.json"
icacls $tenant /inheritance:r /grant:r '*S-1-5-18:(F)' '*S-1-5-32-544:(F)'
Restart-Service LeveeService

See Enterprise deployment for deploying it with Intune or Configuration Manager.

When the service starts, it creates a stable machine identifier (%ProgramData%\Vediram\Levee\machine-id) and activates the device against your tenant. Activation renews itself silently in the background. If activation fails, for example because the machine is offline or the key was revoked, Levee logs a warning, reports "Some Levee features are unavailable" in the app, and keeps running in local-audit-only mode.

Step 3: Users sign in

Policy is downloaded as the signed-in user, so each user signs in once in the Levee app:

1. Open Settings in the Levee app.
2. In the Vediram Cloud card, click Sign in.
3. The system browser opens the Vediram sign-in page. Sign in with your Vediram account.
4. Back in the app, the card shows Signed in, followed by the sync result.

After the first sign-in, Levee keeps the user signed in silently. The user's sign-in token stays in the user's own profile (%LOCALAPPDATA%\Vediram\Levee\) and is never handed to the Levee service or to the sandbox.

If the session expires, the card shows "Session expired - sign in again". Sign out disconnects the app from Vediram Cloud. The last policy already on the machine stays in force.

Step 4: Author the policy

Create the policy in the Vediram Portal. See Managing policy in the Portal for the editor, and How policy works for what each section does.

When does policy sync?

While a user is signed in, the app checks for a new policy at start, on reconnect, every 5 minutes, and when the user asks. It only downloads a policy that changed.

The checks happen:

• when the app starts,
• when the app reconnects to the Levee service,
• every 5 minutes, and
• when the user clicks Sync now.

The Vediram Cloud card shows the outcome:

What happens when the device is offline or a sync fails?

Levee keeps enforcing the last policy it applied. A new policy is applied completely or not at all.

• The last applied policy stays in force. If the device is offline, the sign-in expired, or the Portal is unreachable, Levee keeps enforcing the policy it has. The policy file on disk is the last-known-good copy.
• A policy is applied completely or not at all. A partial or malformed download is never applied.
• Changes apply live. A new policy takes effect for new requests immediately. Running projects don't need to restart.

How does Cloud policy combine with a local policy.json?

The Cloud policy is merged onto the device's policy.json, section by section:

• A section the Cloud policy contains replaces that section on the device.
• A section the Cloud policy omits keeps its current local value. Omitting a section is never a reset.
• Web access is the exception. It always comes from the Cloud policy, and defaults to deny if the Cloud policy doesn't allow anything. A stale local web-access rule is never inherited.

So you can manage the web-access rules centrally, and still deliver, for example, database rules through your own configuration management.

Plugins from the Cloud policy (preview)

Plugins your organization enables in its Vediram Cloud policy are downloaded by each activated device, verified, and offered to projects once they are ready. Removing a plugin from the policy removes it from the devices. See Plugins for what plugins are and how to turn them on.

• The device downloads the plugins, with its own activation, not the user's sign-in. A device without a valid tenant-config.json gets no cloud plugins.
• Each download is checked against its expected size and SHA-256 before it is used. A plugin is offered to projects only once it is ready, never half-started.
• The plugin list is kept on the device in %ProgramData%\Vediram\Levee\plugins.json, and the downloaded plugins under plugins\cloud\. See Files & locations.
• The device checks again when the service starts, whenever a policy with a new plugin list is applied, and every 30 minutes, so secrets your organization sets or rotates later reach the device.
• Some plugins need a value only the user can give, such as a personal token. Users enter it in the Levee app under Settings > Plugins, which lists the plugins your organization enabled and their status. The values are stored encrypted on the machine and belong to the user who first saved them.

Audit forwarding

Audit forwarding sends a copy of each audit event to Vediram Cloud, so you can review activity across all devices in the Portal. It is off by default, and the local audit log is always kept either way.

Turn it on with Forward audit telemetry to the cloud in the General section of the policy in the Portal. The setting takes effect without restarting anything.

Forwarding needs both:

1. an activated device (a valid tenant-config.json), and
2. the forwarding setting turned on in the policy that applies to the device.

What is sent: for each audit event, its time, event type, the resource it concerns (for example a domain or a model name), the event detail, the Windows user name, and the project session it belongs to, plus usage metrics. Model prompts and responses, file contents, and credentials are not part of the audit log, so they are never forwarded. Some events do record what the agent asked for, such as a web search query or a SQL statement, and that detail travels with the event. See the Audit event reference.

Reliability: events are queued on disk (%ProgramData%\Vediram\Levee\levee-telemetry-spool.db) until they are delivered, so a device that is offline for a while catches up later. Forwarding never blocks or replaces the local audit log. If forwarding fails, the local record is still written.

View forwarded activity in the Portal under observability and the audit trail. Administrators with the audit export permission can export it as CSV or JSON. See Activity & audit.

Where does the data live?

Decisions are made on each computer. Vediram Cloud holds your settings, and audit events only if you turn forwarding on.

• Policy decisions and enforcement happen on the device. Agent traffic is processed on the workstation and does not pass through Vediram Cloud.
• Vediram Cloud stores your policies, the list of activated devices and users, and, only if you turn forwarding on, the forwarded audit events.

Rotating or revoking a provisioning key

1. Create a new key in the Portal.
2. Deploy the new tenant-config.json and restart LeveeService on each machine.
3. Revoke the old key in the Portal.

Devices that still hold a revoked key fall back to local-audit-only mode at their next activation.

Troubleshooting

• The card says Sync failed: check that the user can reach Vediram Cloud through the system proxy, then click Sync now. The reason is in the app log: levee log tail --component app.
• The app shows "Some Levee features are unavailable" after deploying tenant-config.json: the device could not activate. Check the key, network access, and levee log tail --component service.

See Collecting logs before contacting support.