Security — Built secure, not bolted on

1. Security Architecture 2. Tenancy & Isolation 3. Authentication & Credentials 4. Read-First Execution 5. Encryption & Key Custody 6. AI Execution Security 7. Access Control 8. Governance, Audit & Evidence 9. Network Posture 10. Resilience & Incident Response 11. Shared Responsibility 12. Responsible Disclosure 13. Customer Recommendations

01 · Architecture

Security Architecture Overview

Two questions decide whether a delivery automation platform is safe to put near an enterprise estate: where the customer’s content lives, and what the platform is able to change without being told. geneworks.ai answers both structurally rather than procedurally.

Content lives in a dedicated, single-tenant environment provisioned for you and nowhere else. Change is gated by two mandatory human approvals that are part of the execution path rather than a setting on it. Nothing is installed in your ServiceNow instance, and no service on your side listens for a connection from ours.

// Trust boundaries — where content lives and how it moves Global Edge web app over HTTPS with single sign-on × no instance credentials × no project content ↓ secure tunnel · outbound-initiated only Your environment AWS · single tenant · yours alone all application services · all your project content all evidence · all analysis data · all credentials ↓ authenticated REST · outbound only · TLS 1.2+ Your ServiceNow remains the system of record read-only for analysis · written only after sign-off Shared control plane accounts · entitlements · billing · usage metering × metadata only × never project content

Principle	How it is enforced
One environment per customer	Dedicated compute, storage and encryption boundaries. Isolation is infrastructural, not a query filter.
Outbound-initiated only	No inbound ports, no VPN, no tunnel into your network, no MID Server, no installed agent or appliance.
Nothing installed in the instance	No plugin, scoped application or update set is required for core operation.
Read-only analysis	Every assessment surface reads. None of them can write, regardless of what is asked of it.
Reviewed, reversible change	A change leaves the loop only after two named approvals, packaged as a scoped update set that can be backed out.
Customer-held keys	Encryption at rest runs under customer-managed KMS keys, so the customer can revoke access independently.
Metadata-only control plane	The only shared component holds account, entitlement, billing and usage metadata. Never project content.

02 · Tenancy

Tenancy & Isolation

geneworks.ai is not conventional multi-tenant software. Each customer receives a dedicated environment on AWS running every application service and holding every piece of their content: project workspace, analysis data, run history, generated artifacts, evidence and stored credentials.

Zone	Tenancy	What runs there
Global Edge	Multi-region	The web application over HTTPS with single sign-on, connecting inward through a secure outbound-only tunnel. Holds no credentials and no project content.
Dedicated Customer Environment	Single tenant	Every application service and all customer data. One isolated node per customer.
Customer ServiceNow Instance	Customer-owned	Reached with credentials you supply and can revoke at any moment.
AI Inference Layer	Frontier models	Reached over a private, region-pinned path. The provider is contractually barred from training on customer data.
Shared Control Plane	Metadata only	Accounts, entitlements, billing, usage metering.

Within an environment, every record and every request is scoped to the caller’s organization and workspace, enforced in the authorization layer. Underneath that layer, another customer’s content is not present in the system at all.

The sentence that ends the isolation question in a security review. Isolation is at the infrastructure layer, not the application layer. There is no multi-tenant database with row-level separation, and therefore no class of application-layer defect that could expose one customer’s content to another. Cross-tenant learning does not occur.

03 · Credentials

Authentication & Credential Custody

Connection to ServiceNow uses OAuth 2.0 with customer-supplied credentials, operating as a dedicated integration user under a least-privilege scoped role set. The admin role is not required.

Held in your environment only. Instance credentials and OAuth client secrets live inside your dedicated environment, never in a shared component and never in the edge tier.
Encrypted twice. Secrets receive an additional layer of application-level authenticated encryption before being written, on top of encryption at rest. Key material exists only in the backend runtime, never in the interface, in logs, or in source control.
Never exposed to an agent or a model. Agents reach ServiceNow through the integration layer as a controlled set of scoped operations. No agent and no model ever holds a raw credential.
Attributable. Every platform action is performed as the integration user and appears in your own ServiceNow audit log alongside the platform’s own record.
Revocable by you, instantly. Disabling the integration user or the OAuth application in ServiceNow severs access immediately, without involving geneworks.ai.

Use a dedicated integration user, never a personal account. It gives you a clean audit trail, lets you revoke platform access independently of any individual, and keeps the role set reviewable. Start it read-only and grant write roles when you move to remediation.

04 · Read-First

Read-First Execution Model

Every surface follows the same shape: read, score, propose, you approve. The read is strictly read-only. It reads configuration records, the dictionary, audit and metadata to build its map, score or findings, and writes nothing back.

// The read/write boundary is explicit per surface Surface Reads Writes Command Center tables, relationships, sys metadata none Application Explorer app artifacts, customizations none CMDB Rapid Assessment cmdb_ci, dictionary, audit none Catalog Center catalog items, variables, scripts none Upgrade Assist release notes × instance state none Normalize source tables + reference catalog none until you apply Process Analyst process and platform state none The delivery loop target state, read before write only after sign-off

Remediation is a separate and deliberate act. Accepting a finding opens governed work that runs the same two-gate loop as any other change. Nothing is applied silently, in bulk, or without a named approver.

Writes are a distinct operation class. Read and analysis operations are separated from write operations inside the integration layer. A write requires three things at once: a user who initiated it deliberately, a workspace where that user holds the role, and a design that has already cleared its gate.

The assessment tool is also the remediation tool, but never in the same moment. Diagnosis is read-only and immediate. Remediation is explicit, reviewed and reversible.

05 · Encryption

Encryption & Key Custody

Layer	Control
In transit	TLS 1.2+ on every external connection, without exception. An instance endpoint that does not serve a valid certificate cannot be connected.
At rest	AES-256 throughout the dedicated environment, under customer-managed KMS keys.
Credentials and secrets	An additional application-level layer of authenticated encryption before storage.
Platform secrets	Injected at deploy time through managed secret storage. Workloads use short-lived, role-based cloud identities rather than long-lived static credentials.

Customer-managed keys change what a control means. Because the keys are yours, you can render your own data inaccessible without involving geneworks.ai and without waiting for a support ticket. That converts a line on a security questionnaire into a control you actually hold.

06 · AI Execution

AI Execution Security

Between the agents and the frontier model sits the geneworks.ai harness. It decides what context an agent receives for a piece of work, which tools it may use, how tool results are validated before they are trusted, and when a run must stop and ask a human. Model output is never the last word on whether something is done.

Governed tool access. Every action against your instance passes through the integration layer as a scoped, audited operation. A model cannot reach ServiceNow directly, cannot widen its own scope, and never sees a credential.
Read before write. Before creating or modifying any artifact, the responsible agent reads the current state of the target and merges changes made since the last deployment, so it does not overwrite work somebody else did in the meantime.
No autonomous background execution. Agents do not act against your instance outside work you started. No scheduled jobs, no webhook that triggers execution without you, no persistent session running unattended.
Prompt-injection resistance. System instructions are separated from user and record content. Text inside an uploaded document, a catalog item or a scanned record cannot alter agent behavior, security constraints or governance rules.
Bounded roster. Specialist agents work under orchestration, each scoped to its discipline. No agent escalates beyond the connected integration user’s permissions, because there is no path by which it could.
No training on your content. The inference provider is contractually prohibited from training on customer data, and geneworks.ai does not train, fine-tune or improve any model on customer content. Inference runs over a private, region-pinned path.

// Defenses applied to every agent action, not to every agent prompt Scope fence injected server-side into every agent context before the model sees it. Not reachable or modifiable at runtime. Blocked classes mass deletion · table truncation · credential modification · privilege escalation → refused at the execution layer Scoped writes every write lands in a named update set, never in Default. Honest failure a partial build is reported as a partial build. A failing test is never recorded as passed.

07 · Access Control

Access Control & Permissions

geneworks.ai operates inside your instance’s own permission model. Agents can only perform actions the integration user is authorized to perform, and the platform does not attempt to escalate privilege or work around an ACL.

Least privilege, staged by phase. Grant only what the work in front of you needs:

Phase	Access	Why it is enough
Assessment	Read-scoped role set	Every assessment surface reads. Nothing in this phase can write.
Delivery	Scoped write role set	Sufficient for configuration work in the modules in scope. The admin role is not required.
Platform-wide work	Broader role set	Needed only where the work itself touches roles, ACLs or platform-wide configuration.

Inside the platform, users are invited into your organization by an administrator and assigned per-workspace roles. Roles govern both visibility and capability, in particular who may run read-only analysis and who may initiate build, change and test execution. A user cannot see a workspace they have not been granted, and can never reach another customer’s organization.

08 · Governance

Governance, Audit & Evidence

Two approvals are architectural. A named architect approves the design before anything is built, and a named reviewer examines the evidence package before anything is handed over. Medium and high risk require an explicit sign-off on the risk level itself. Neither gate is configurable, and there is no path through the conversational interface that avoids them.

Capability	Can	Cannot
Analysis	Read the instance to map, score and classify	Write anything during a scan
Change	Design, build, test and package on approval	Promote between instances outside your change process
Credentials	Store encrypted, rotate, use through the integration layer	Expose a raw credential to an agent, a model or the interface
Update sets	Create, name, scope and manage	Commit to production. That remains your action
Testing	Write and run automated and functional tests	Record a failing test as passed
Sign-offs	—	Bypass either human gate

Every agent action, human approval and deployment is logged with actor, timestamp and payload reference. Evidence from a verification run — results, screenshots, video, logs — is retained immutably against the run that produced it, and both gates record the identity of the approving reviewer.

Why this matters commercially, not just technically. The risk in AI-assisted delivery is not that a model produces something wrong. It is that afterwards nobody can prove what changed, why, on whose authority, and whether it was tested. Conventional delivery assembles that evidence by hand at the moment someone asks for it. geneworks.ai produces it as a by-product of execution, at the moment of execution, and stores it immutably.

09 · Network

Network Posture

Outbound-initiated, always. No inbound ports on the customer side, no VPN or site-to-site tunnel, and no listening service exposed to the internet from your estate.
Nothing installed in your network. No MID Server, agent or appliance. The integration is a standard authenticated REST connection over HTTPS.
Private inference path. Model access runs over a private, region-pinned route rather than the public internet.
Egress ranges published. Allow-list them on the ServiceNow instance where your policy requires it. Addresses are provided during onboarding.
Private internal services. Within the dedicated environment, application services have no public endpoints and are reachable only on the private network.

Workloads run across multiple availability zones in private subnets. Least-privilege identity is applied per service, with security groups restricting traffic between them.

10 · Resilience

Resilience & Incident Response

Services are deployed across multiple availability zones and reschedule automatically on node or zone failure. Databases take automated backups with tested restore procedures, and object storage is versioned. Because your ServiceNow instance remains the system of record, recovery consists of restoring platform state and re-reading the instance rather than reconstructing your data from ours.

All platform changes flow through version control and peer review before deployment, and production deploys are traceable to reviewed commits. Dependency and container image scanning runs in the build pipeline with risk-prioritized patching. Customer data is never used in development or testing.

Stage	Timeframe	What happens
Initial assessment	≤ 24 hours	Scope, severity and nature of the incident established.
Customer notification	≤ 72 hours	Affected customers notified of the nature of the incident, the data potentially affected, and the steps taken or planned.
Remediation	Ongoing	Contain, remediate, prevent recurrence, with progress communicated throughout.
Post-incident review	≤ 30 days	Report made available to affected customers.

The blast radius is structurally limited. Because every customer has a separate environment, an incident is bounded to the environment it occurs in. There is no shared runtime and no shared database through which it could reach another customer.

11 · Shared Responsibility

Shared Responsibility

Operated by geneworks.ai	Retained by you
Provisioning and operating the dedicated environment	The ServiceNow instances and the data in them
Monitoring, security patching and platform updates	Encryption keys, in your own KMS
Encryption and custody of stored instance credentials	Provisioning and lifecycle of the integration user and its role set
Governance and audit of agent actions on the platform	Which instances are connected, and at what access level
Model access and inference routing	Content and data hygiene of the connected instances
Subprocessor management	User and role management inside your organization
—	Change management, promotion decisions, and the named reviewers at both gates

Platform updates are applied by geneworks.ai to your dedicated environment. There is no ServiceNow upgrade, no update set and no change window on your side.

12 · Responsible Disclosure

Responsible Disclosure Policy

We welcome security researchers to responsibly disclose vulnerabilities found in the geneworks.ai platform. If you find one, please:

Email a detailed description with the subject line “geneworks.ai Security Disclosure”.
Include steps to reproduce, the potential impact, and any proof-of-concept code.
Allow a reasonable window of 90 days to investigate and remediate before public disclosure.
Do not access, modify or exfiltrate customer data during your research.
Do not perform denial-of-service testing, social engineering or physical security tests.

We acknowledge receipt within 5 business days and will not pursue legal action against researchers who follow this policy in good faith. Reach us at gene@geneworks.ai.

13 · Recommendations

Recommendations for Customers

Start read-only. Connect with a reduced-privilege integration user, run the assessment surfaces, and grant write roles only when you are ready to remediate.
Use a dedicated integration user with the minimum role set the work requires. Never a personal account, and never one shared with another tool.
Enable audit logging on that account, and monitor its activity in your own audit tables. You should not have to take our word for what happened.
Name your gate reviewers explicitly, and make sure they have the standing to reject a design. A gate staffed by someone who cannot say no is not a gate.
Build in sub-production first and promote through your normal change process. geneworks.ai packages the change; the decision to commit it to production stays with you.
Review access periodically. Remove users who no longer need a workspace, and rotate integration credentials on your normal schedule.
Encode your standards. Naming conventions, update set discipline and review criteria are cheaper to enforce by construction than by review.

Security is the architecture, not a policy promise. Single tenancy, outbound-only connectivity, read-only analysis, customer-managed keys and two human gates are enforced by construction. None of them depends on anyone remembering to do the right thing.