Relevant information
Define which records and sources each person and assigned agent may use. Review permitted reads, data paths and model access for the selected deployment.
Security and deployment
Set the boundaries before work begins.
Agree what each person and assigned agent may access, reveal, recommend and change. Name the approval and exception owners before data access. Choose Nodes Cloud, a single-tenant customer VPC or customer-managed on-premises infrastructure; the selected boundary governs data, models, workflows and records.
SOC 2 Type II attested · HIPAA and GDPR aligned · Named human authority · Review scope and evidence
Information and visibility
Choose the sources and checking frequency.
Your company chooses the internal records, external sources and checking frequency for the question. Local experts explain relevance and exceptions. Agree these boundaries before access and review them whenever the scope changes.
Interaction visibility
Agree who can see source records, team interactions, recommendations and results. Set recording, access and retention rules for the scoped work.
Permitted actions
Separate permission to recommend from permission to change a system. Name required approvals, the exception owner and the conditions that pause work.
Deployment options
Choose the operating boundary your work requires.
The selected deployment boundary covers Nodes Engine, Nodes Connector and Nodes AI FDE, including their data access, model connections, permitted actions and retained records.
Review the actual data flows for the chosen deployment, including tools, support access, telemetry and backups. Compare supported model options against task quality, exception limits, total cost and permitted-data requirements. A model change requires evaluation and configuration.
Deployment boundary mapSame governed core · different operating perimeter
Nodes-managed cloud deployment.
Data, model access, isolation, retention, and telemetry are defined inside a Nodes-managed operating boundary and the customer agreement.
Managed
Single-tenant inside the customer's cloud.
Run the platform inside an approved AWS, Azure, or GCP boundary with private data paths. Confirm the supported model configuration for the agreed task.
VPC-resident
Customer-managed infrastructure.
Run the platform, models, agents, workflows, and Decision Traces inside an approved on-premises environment.
Customer-managed
Zero customer production-data egress.
Private VPC and on-premises configurations can keep customer production records and customer-specific intelligence inside the approved customer boundary. Verify all model, connector, and operational paths.
Configuration-specific
Boundary and responsibility
Assign each control for the chosen deployment.
Nodes Cloud runs in a Nodes-managed boundary. A customer VPC is single-tenant inside the customer's approved cloud. On-premises uses customer-managed infrastructure. The agreement names the operator and support path for each control; these questions apply to all three choices.
How do we control what AI agents are allowed to do?
Give each agent only the records and actions it needs. Set spending and approval rules, an exception owner and a way to stop it. Enforce the limits in software and test a denied request.
Can AI follow our existing employee access permissions?
Yes, when each connected source is configured to honor the intended user rights. A shared service account may have broader access, so test both allowed and denied records and actions.
Can we run AI inside our private cloud?
Yes, Nodes offers a single-tenant customer VPC deployment. Check the model, storage, logs, tools and support routes before deciding whether any data leaves that boundary.
Can we run enterprise AI on our own servers?
Yes, where the software and model support customer-managed on-premises infrastructure. Agree the hardware, operations, updates and any external dependencies for that configuration.
| Area | Responsibility to assign | Check in the selected configuration |
|---|---|---|
| Identity | Who issues and revokes user and service identities? | Test a permitted user, a denied user and a revoked identity. |
| Source access | Who grants each read scope and handles a source change? | Compare employee rights with any shared service-account rights. Test both allowed and denied records. |
| Actions | Who sets action scopes, approval gates and exception owners? | Try an allowed action and a blocked write. Confirm that approval never widens current system permissions. |
| Models | Who selects and operates each model route? | Trace prompts and tool results to local or approved hosted inference. Record any egress. |
| Logs | Who controls access, retention and review? | Locate the action log and Decision Trace, including any operational telemetry path. |
| Support | Who may access the environment for diagnosis? | Check support access, its approval path and what data can leave the boundary. |
| Backups | Who operates and restores each backup? | Identify where retained context and logs are copied and test the agreed recovery path. |
| Updates | Who schedules, tests and applies changes? | Test model, connector and software changes against permissions and workflow acceptance checks. |
Private hosting alone does not establish zero external data flow. Review the actual model, tool, telemetry, support, backup and update routes. See one narrower VPC hiring configuration; its data paths do not describe every deployment.
Attestation and alignment
SOC 2 Type II attested. HIPAA and GDPR aligned.
The SOC 2 Type II report is available under NDA. HIPAA and GDPR describe operational alignment, not certifications. Each deployment requires review of its configuration, customer obligations, and applicable agreements. Inspect the scope and materials.
SOC 2 Type II · attested
HIPAA · operationally aligned
GDPR · operationally aligned
Deployment compliance · customer and counsel review
Security materials
Review the reports and planned terms.
Request the SOC 2 Type II report under NDA and the data-flow diagram for your selected deployment. The DPA and subprocessor schedule remain in preparation; their previews are nonbinding and do not create or amend contractual terms.
Auditability
Inspect the evidence and authority behind the action.
Configurable role-based access, approval gates, automated policy enforcement, agent inventory, telemetry, audit logs, monitoring and pause/revoke controls govern Nodes agents. Oversight of third-party agents is available case by case.
Nodes works within configured permissions. Actions requiring approval remain gated by the customer's policy. Prior approval is context; current permissions determine what Nodes may do. Routine steps stay within that authority.
A Decision Trace connects evidence, recorded reasoning, versions, human questions and edits, approval, action and later outcome. People inspect and challenge the record within their access rights. Failed and inconclusive results remain part of the company knowledge.
Test permission revocation, an edited plan and a partially completed action. Customer-designated workflows can require a second signer. Begin with analysis; the owner expands, holds or narrows delegated work after reviewing agreed quality, risk, exception and total-cost checks. A favorable result alone grants no new authority.
Integration controls
Test the stop condition before trusting the connector.
Confirm integration feasibility, permitted reads and actions, system owners and dependencies for the scoped workflow. Test how uncertain mappings or a changed field pause work and reach the exception owner. Agree implementation and maintenance coverage for that environment.
01
Permissions and data paths
Use existing authentication and least-privilege scopes for every connected system.
02
Mapping confidence
Record why each source field maps to a canonical definition and where confidence is limited.
03
Human acceptance
Require an approval record before uncertain evidence enters a decision program.
04
Schema change
Pause the affected flow and route the change for review instead of silently remapping it.
One reference deployment
Legal approval took 17 days after six vendors were rejected on architecture.
The same Fortune 500 insurance deployment moved from contract to production in 34 days. These observed results describe one customer environment and do not promise the same timeline elsewhere.
17 days · legal approval
34 days · contract to production
Live since January 2025
SOC 2 Type II attested
Ownership and exit
Your company owns its agreed knowledge and history.
Your company owns the customer-specific knowledge graph, context and history defined in the agreement: source evidence, relationships, human judgments, Decision Traces, outcomes and applicable learned artifacts. Customer-specific weights and calibration artifacts are included where they exist and the agreement defines them.
Practical portability needs a sample export. Ask which records it contains, how identifiers and relationships survive, which schemas and provenance come with it, and what remains usable without Nodes. Agree retention, formats, transition support, and any release or escrow terms before production.
Customer ownership does not provide indefinite use of Nodes' licensed runtime. Nodes retains its platform code and pre-existing reusable intellectual property; agent operation, connector maintenance, updates, and support follow the service agreement. Confidential company memory is not pooled across tenants by default.
Security library
Inspect the architecture behind the claims.
These technical explainers remain available for security and procurement review.
Diligence
Map the data paths, approvals, and stop conditions.
Bring one question or workflow and its accountable owner. Review source access, recommendation scope, proposed actions and deployment requirements. No company data is needed for the first conversation.