Proactive graph building, read-only connections, and permissions
Proactive graph building does not change what SIGNLD is allowed to access. It changes when the Knowledge Graph starts drafting structure from a connected system, not the permissions behind that connection. Proactive Knowledge Graph building is in beta in SIGNLD as of October 2026, with general availability planned for early 2027.
In this article
- The permission model does not change
- What proactive building actually does with a new connection
- Tenant isolation and where inference happens
- Why proposals still need a human, security aside
- What SIGNLD does not do
- Questions security teams ask first
- Auditability of proposals
- How this interacts with existing connector permissions
- Comparison: reactive vs proactive, same permission boundary
- What changes for a compliance review during beta
- Where SIGNLD fits
- FAQ
The permission model does not change
Every SIGNLD connection is read-only. That was true before proactive graph building and it is true now that the graph drafts structure as soon as a system connects. Proactive building reads the same schema, tables, and records a reactive connection would eventually read once someone asked a question about them. It does not request write access, it does not create new scopes, and it does not need broader permissions than a single-source connection already required on day one.
For the wider context, see our explainer on what a proactive knowledge graph is.
What proactive building actually does with a new connection
Once a read-only connection completes, SIGNLD's graph-building process inspects the structure of that system, the tables, fields, and record types, and proposes candidate entities and relationships, including likely matches to entities already known from other connected systems. This happens on the data SIGNLD already has permission to read. Nothing about the process asks the source system for anything beyond what a normal connection already retrieves.
The output of this process is a set of proposals, not a finished graph. SIGNLD does not claim the graph it builds proactively is complete or correct without review; a person still confirms what gets treated as settled, exactly as with graph structure learned reactively from chat and queries.
Tenant isolation and where inference happens
Each SIGNLD tenant's data, including the Knowledge Graph and everything proactive building proposes into it, is isolated from every other tenant. AI inference used in graph building and in answering questions runs on a single-tenant AWS Bedrock instance, not a shared model instance serving multiple customers. SIGNLD is never trained on your data. These controls sit under SOC 2 Type II, and they apply the same way whether the graph is being built reactively through use or proactively from a new connection.
SIGNLD does not claim zero egress or that data never leaves your environment. Read-only connections retrieve data into SIGNLD's isolated tenant environment so the graph and the Decision Briefs can be built; the controls that matter are isolation, read-only access at the source, and controlled inference, not a claim that nothing moves.
Why proposals still need a human, security aside
Proactive building surfaces relationships and entity matches earlier than the reactive model did, purely as a mechanical difference. It does not grant the graph any new authority to decide, on its own, that two records represent the same customer or that a relationship is confirmed. A proposal with low confidence is flagged for review rather than written into the graph as fact. This is a product design choice as much as a security one: faster proposals are useful only if the person reviewing them can trust that nothing was committed without a chance to check it.
What SIGNLD does not do
SIGNLD does not write back to any connected system, proactively or otherwise. It does not expand its own access scope based on what it discovers while building the graph. It does not move proposed entities into a "confirmed" state without a review step being available. And it does not use one tenant's data, structure, or proposed graph to inform another tenant's graph or model behavior.
Questions security teams ask first
Security reviewers evaluating proactive graph building typically ask three things: what new access does this require, where does inference run, and can the system commit a change without a person seeing it first. The answers are consistent: no new access beyond the existing read-only connection, single-tenant AWS Bedrock inference under tenant isolation, and no, proposals require confirmation before they are treated as settled graph structure.
Auditability of proposals
Because proactive building produces proposals rather than final graph structure, each proposal carries a record of what it matched, what confidence signal it was given, and whether a person confirmed, corrected, or dismissed it. This gives a security or compliance reviewer a trail to check: not just what the graph currently believes, but how it arrived there and who approved it. That trail exists whether the underlying proposal came from a reactive learning event, like a question that revealed two records were the same entity, or from a proactive scan of a newly connected system's structure.
This matters for teams that need to demonstrate, after the fact, that no automated process silently changed how a business entity like a customer or a product was represented. The review step is not just a product safeguard against bad matches; it is also the record that shows a human made the call.
How this interacts with existing connector permissions
SIGNLD's connectors are read-only by design across the platform, not only for proactive graph building. A connector authenticated for finance data, for example, is scoped to read the tables and records that connector type exposes, and that scope is set at connection time regardless of whether the graph subsequently learns about that system reactively or proactively. Turning on proactive graph building for a tenant does not trigger a re-authentication with broader scope, and it does not change what a connector is able to request from the source system. The distinction that matters to a security reviewer is between what a connector can read, which is fixed and read-only, and what SIGNLD's graph-building logic does with what it has already been permitted to read, which is where proactive versus reactive behavior differs.
Comparison: reactive vs proactive, same permission boundary
| Control | Reactive graph building | Proactive graph building |
|---|---|---|
| Connection type | Read-only | Read-only |
| Access scope | Limited to connected system | Same, unchanged |
| Tenant isolation | Enforced | Enforced |
| Inference environment | Single-tenant AWS Bedrock | Single-tenant AWS Bedrock |
| Trained on customer data | No | No |
| Graph changes committed without review | No | No |
What changes for a compliance review during beta
Because proactive graph building is in beta, teams running a compliance review during this period should expect the same controls documented for the general availability release, with the caveat that the feature set proposing entities and relationships is still being refined. The controls that do not change during beta are the ones a review typically focuses on: read-only connections, tenant isolation, SOC 2 Type II scope, and single-tenant inference. What may change between now and general availability is the accuracy and coverage of what gets proposed, not the boundary around what SIGNLD is allowed to touch.
Where SIGNLD fits
SIGNLD is a decision intelligence platform that unifies connected business systems into a private Knowledge Graph and returns ranked, traceable Decision Briefs. Proactive graph building changes how early the graph starts drafting structure from a connection; it does not touch the read-only access model, tenant isolation, or the SOC 2 Type II controls that govern every connection. Full detail on the platform's security posture is on the security page. See the roadmap for what is planned as proactive building moves toward general availability, and how it works for the mechanics of a Decision Brief.
Related reading in this series: Proactive Knowledge Graph building in SIGNLD: what changes and What you still control when the graph builds itself.
Key takeaways
- Once a read-only connection completes, SIGNLD's graph-building process inspects the structure of that system, the tables, fields, and record types, and proposes candidate entities and relationships, including likely matches to entities already known from other connected systems.
- Proactive building surfaces relationships and entity matches earlier than the reactive model did, purely as a mechanical difference.
- Security reviewers evaluating proactive graph building typically ask three things: what new access does this require, where does inference run, and can the system commit a change without a person seeing it first.
- SIGNLD's connectors are read-only by design across the platform, not only for proactive graph building.
- On a single-tenant AWS Bedrock instance dedicated to your tenant, under SOC 2 Type II controls, with tenant isolation enforced between customers.
FAQ
Does proactive graph building need more permissions than a normal connection?
No. It reads the same schema and records a read-only connection already retrieves. Proactive building changes when SIGNLD starts drafting graph structure from that connection, not what it is permitted to access. The permission boundary is identical to a connection used only reactively.
Where does SIGNLD run the AI models used for graph building?
On a single-tenant AWS Bedrock instance dedicated to your tenant, under SOC 2 Type II controls, with tenant isolation enforced between customers. SIGNLD is never trained on your data. This applies to graph building whether it happens reactively through use or proactively from a new connection.
Can proactive graph building commit a change without anyone reviewing it?
No. Proposed entities and relationships, particularly lower-confidence matches, are flagged for review rather than written into the graph as settled fact. A person confirms or corrects proposals before SIGNLD treats them as part of the working Knowledge Graph.
Does SIGNLD claim zero data egress for proactive graph building?
No. SIGNLD does not claim zero egress or that data never leaves your environment for any part of the platform, including proactive graph building. The controls that apply are read-only source access, tenant isolation, and single-tenant inference, documented in full on the security page.
Try SIGNLD free or see how it works. Read the proactive knowledge graph overview or the full FAQ.