Permissions and data access in the SIGNLD extension

The SIGNLD extension for Claude only ever reads what a signed-in user already has permission to see inside SIGNLD's Knowledge Graph. It cannot write to connected systems, cannot exceed a user's existing workspace access, and every answer it surfaces stays traceable back to a source record.

What the extension can read

Once a user connects the SIGNLD extension for Claude to their SIGNLD account, Claude can draw on the parts of that company's Knowledge Graph the signed-in user already has access to: entities like customers, vendors, products, and teams; the metrics defined for the business; the definitions those metrics rely on; the rules that govern how numbers get calculated; and decisions already recorded about how something is counted or handled.

For the wider context, see our overview of the SIGNLD extension for Claude.

The SIGNLD extension for Claude is built and maintained by SIGNLD using Anthropic's publicly available extension interfaces. SIGNLD is not affiliated with, sponsored by, or endorsed by Anthropic.

None of that context is a copy sitting inside Claude. The extension reads live from the same graph SIGNLD maintains, so a definition updated in SIGNLD is the definition available the next time that user opens a Claude session with the extension connected.

What it cannot read

The extension cannot read anything a user could not already reach inside SIGNLD itself. It has no separate or elevated access path. If a user's SIGNLD account is scoped to a subset of connected systems or a subset of the Knowledge Graph, the extension is scoped to that same subset inside Claude.

It also cannot write. It does not create, edit, or delete records in any connected system, and it does not push anything back into SIGNLD either. It is a read layer, not a two-way sync.

It does not read raw source system data directly. What it surfaces is Knowledge Graph context, entities, metrics, definitions, rules, and decisions, that SIGNLD has already mapped and resolved. It is not a general-purpose pipe into a company's underlying databases or applications, and it does not bypass whatever access controls those systems already enforce on their own side.

Finally, it cannot see or affect anything about how Claude itself is configured, priced, or limited. Those specifics belong to Anthropic and change on their own schedule. Current details live at docs.anthropic.com.

How workspace and organization permissions carry through

SIGNLD organizes access at the workspace and organization level, and the extension inherits that structure rather than replacing it. A user connecting the extension is authenticating as themselves, with whatever role and workspace membership their SIGNLD account already has.

That means if a person belongs to one workspace inside a larger organization, the extension only surfaces Knowledge Graph context for that workspace inside their Claude sessions, not context that belongs to a different team's workspace in the same organization. If an organization has restricted a metric definition or a set of entities to a specific role, that restriction holds inside Claude the same way it holds inside SIGNLD's own interface.

This matters for teams where finance, operations, and other groups each connect their own systems and maintain their own definitions inside a shared organization. Connecting the extension does not flatten those boundaries. A person on the finance team sees the finance-relevant context they already had access to; a person on the operations team sees theirs. Permissions are enforced once, at the SIGNLD account level, and the extension carries that same enforcement into every Claude session rather than introducing a second permission model to keep in sync.

Read-only connections

Every system SIGNLD connects to is connected read-only. SIGNLD reads records from a company's business systems to build and maintain the Knowledge Graph; it does not write back into those systems, and the extension does not change that posture in any way.

Inside a Claude session, this means the extension can help a user understand what a system contains, but it cannot use that session to update a record, close an opportunity, change an invoice, or take any action inside the source system. The read-only boundary sits at the connection level, underneath both SIGNLD's own interface and the extension, so there is no path through Claude that reaches further into a connected system than SIGNLD's own access already allows.

For the full picture of how connections, tenant isolation, and access controls work across SIGNLD, see /security.

This also means the extension cannot be used as a workaround to get write access into a system a company has deliberately connected read-only. If a team wants an action taken, closing a deal stage, updating a forecast, correcting a record, that action still has to happen inside the source system itself, through whatever process already governs changes there. The extension can help a person understand what needs to change and why; it does not perform the change.

Single-tenant inference for SIGNLD

The AI inference SIGNLD itself performs, resolving entities, generating ranked answers, and scoring confidence, runs on a single-tenant AWS Bedrock instance. That means SIGNLD's own inference workload for a given customer is not sharing compute with other customers' data, and SIGNLD is not trained on customer data.

This applies to the inference SIGNLD performs to build and maintain the Knowledge Graph and to generate the traceable answers that graph supports. It is separate from anything Anthropic does inside Claude itself, which is governed by Anthropic's own infrastructure and policies and documented at docs.anthropic.com, not by SIGNLD.

What an admin controls

An admin on a SIGNLD account controls which systems are connected, which workspaces exist, which roles can see which parts of the Knowledge Graph, and which users on the account are permitted to use the extension at all. None of that changes because the extension exists. Admin-level access controls set inside SIGNLD apply equally whether a person is working in SIGNLD's own interface or in a Claude session with the extension connected.

An admin can also revoke a user's access to the extension the same way they'd revoke access to any other part of SIGNLD, by removing that user's role or workspace membership. Because the extension has no separate login or separate access grant of its own, there is no second place an admin has to remember to check when offboarding someone or adjusting what a team can see. One change inside SIGNLD's admin settings takes effect everywhere that person's account is used, including inside Claude.

An admin does not, however, control anything about Claude itself, its features, its limits, or how Anthropic handles a session on its own infrastructure. That responsibility sits with Anthropic and is documented on Anthropic's own terms.

For how SIGNLD frames its broader responsible use commitments around AI-generated answers, see /legal/responsible-ai. For a fuller look at what the extension does day to day, see SIGNLD extension for Claude.

Related reading in this series: Setting up the SIGNLD extension for Claude and Traceable answers inside a Claude session.

Key takeaways

The extension cannot read anything a user could not already reach inside SIGNLD itself.
SIGNLD organizes access at the workspace and organization level, and the extension inherits that structure rather than replacing it.
The AI inference SIGNLD itself performs, resolving entities, generating ranked answers, and scoring confidence, runs on a single-tenant AWS Bedrock instance.
An admin on a SIGNLD account controls which systems are connected, which workspaces exist, which roles can see which parts of the Knowledge Graph, and which users on the account are permitted to use the extension at all.
SIGNLD's own inference runs on a single-tenant AWS Bedrock instance and SIGNLD does not train on customer data.

FAQ

Can the SIGNLD extension for Claude see systems I haven't connected to SIGNLD?

No. It only surfaces Knowledge Graph context built from systems already connected to SIGNLD. If a system isn't connected, there is no graph data from it for the extension to bring into a Claude session.

Can two people on the same SIGNLD account see different things through the extension?

Yes. The extension inherits each person's existing workspace and role permissions inside SIGNLD. Two people with different access levels will see different Knowledge Graph context in their own Claude sessions, matching what they'd see inside SIGNLD directly.

Does connecting the extension give SIGNLD new access to my systems?

No. Connecting the extension doesn't expand what SIGNLD can access. It only changes where a user can view context that SIGNLD already holds, adding a Claude session as a place to see it alongside SIGNLD's own interface.

Is my data used to train Claude or any model shared with other companies?

SIGNLD's own inference runs on a single-tenant AWS Bedrock instance and SIGNLD does not train on customer data. Anything specific to how Anthropic handles data inside Claude sessions is governed by Anthropic's own policies, documented at docs.anthropic.com.

Who decides which employees can use the extension?

An admin on the SIGNLD account does. Admin-level controls over users, roles, and workspace access apply the same way whether someone works inside SIGNLD directly or through a Claude session with the extension connected.

Try SIGNLD free or see how it works.

Claude and Anthropic are trademarks of Anthropic. Used descriptively only.

Permissions and data access in the SIGNLD extension for Claude

In this article