Security

InstanceGuard runs an independent, read-only assessment of your ServiceNow instance. This page describes exactly how we access your instance, what data leaves it, and how we handle it.

Last updated July 12, 2026

Read-only by construction

Every request InstanceGuard makes to your ServiceNow instance is an HTTP GET. This is not a policy — it is enforced in code:

• Our ServiceNow client exposes no create, update, or delete method. A write literally cannot be expressed.
• A runtime guard re-asserts method === "GET" at the network boundary as defense in depth.
• The integration user you provide must hold ServiceNow's read-only role (snc_read_only), which blocks every write at the platform level. We validate this before a scan begins. The account may also hold broad read roles (e.g. admin) so it can see the configuration being audited — snc_read_only ensures those can never write — and we refuse any account that is write-capable without it.

We cannot, and do not, change anything in your instance.

Exactly what we read

The scan reads a fixed, minimal set of configuration tables, requesting only the specific fields each check needs:

• Access controls — ACL rules and their role assignments (sys_security_acl, sys_security_acl_role), including each ACL's condition and script.
• Server-side logic — business rules and script includes (sys_script, sys_script_include).
• Client-side logic — client scripts (sys_script_client).
• Automation — scheduled jobs (sysauto_script).
• Privileged access — role assignments (sys_user_has_role): the username of each role holder and the role name.
• Recent customizations — records changed in the last 90 days (sys_update_xml).

Script bodies: for code-quality and security checks (e.g., detecting eval() or unsafe queries), the script source of the records above is read as evidence. Be aware this means script content leaves your instance.

What we do not read: The current audit manifest is limited to the configuration and security-metadata tables listed above. InstanceGuard does not request incident, task, HR case, attachment, or journal-entry content as part of the standard assessment. The only user data read is the username of privileged-role holders, to analyze access — not profile fields such as email, phone, or personal data.

Where your data goes

Your ServiceNow instance
  │  read-only GET of the configuration tables above
  ▼
InstanceGuard rules engine        (deterministic scoring, our servers)
  │  versioned redaction of finding evidence
  ▼
Anthropic Claude API              (plain-language explanation only)
  │
  ▼
Supabase (PostgreSQL)             (tenant-isolated, encrypted at rest + in transit)

Credentials

Connection credentials — an OAuth client secret, or a read-only service-account password — are stored in Supabase Vault; only an opaque reference is kept in our database. They are never written to application logs or error payloads. InstanceGuard supports OAuth where your instance allows it.

AI analysis & the data that leaves your instance

Findings are scored by a deterministic rules engine on our servers — no AI decides severity. To turn a finding into a plain-language explanation, the relevant evidence is sent to a third-party model provider (Anthropic's Claude API). Before any evidence is sent, it passes through a versioned redaction step. Per Anthropic's commercial terms, data submitted through the API is not used to train their models.

Be transparent: today a redacted subset of finding evidence does leave your environment (to our servers and to Anthropic). We do not imply otherwise.

Storage & encryption

Assessment data is stored in Supabase (PostgreSQL) with row-level security isolating each customer's data, encrypted in transit (TLS) and at rest. Data is hosted in the US East region (North Virginia).

Auditability

• Analyses are append-only and versioned — every explanation is tied to the exact evidence, model, and prompt version that produced it.
• Reports are reviewed by a human before delivery.
• Provider API keys are never logged or stored in analysis records.

Data retention & deletion

InstanceGuard does not currently auto-expire data — assessment data and reports are retained until you request deletion. Removing a connection archives it; to permanently delete a connection, its stored credential, and its assessment data, email Sabnam.Memon@livteq.com and we will remove it. (Automated retention is a planned control; today deletion is handled on request.)

Compliance

InstanceGuard is not currently SOC 2 certified. Security controls and documentation are being developed as the product enters controlled pilots. For data-processing terms, contact us.

Reporting a vulnerability

Found a security issue? Email Sabnam.Memon@livteq.com. We'll acknowledge and respond promptly.

About InstanceGuard · Privacy