Security and Governance

The trust story for Project Synapse, in plain terms.

Agents can look, but never touch

Agents connect to systems like ServiceNow and Azure DevOps to pull in information that informs what they draft or recommend — looking up an incident, searching related work items. What an agent can never do is make a change in one of those systems directly.

That's not a policy someone could forget to enforce. It's built into how requests are routed: the part of the platform that lets an agent act is only ever handed the "look things up" capabilities. The "make a change" capabilities are structurally excluded from what any agent can reach, no matter how that agent happens to be configured. If something needs to be created or updated in a real system, that request has to go through a separate, human-gated step — every time, with no exceptions.

Reference material cannot rewrite the rules

Content from a knowledge pack, uploaded document, connector, or tool — plus a signed webhook, earlier workflow step, or prior model output — is treated as reference data, never instructions. Project Synapse puts each source inside an explicit, trust-labelled data section. A platform-owned policy tells the model that content inside those sections cannot expand its capabilities, change the signed-in identity, remove an approval, or replace the agent's task. A valid webhook signature proves where data came from; it does not promote that data into policy.

The platform also escapes delimiter text found inside a document or connector response, so untrusted content cannot close one data section and imitate a trusted one. Suspicious collisions are recorded as bounded signals without copying the matched attack text into the run UI or logs. Detection is useful evidence, but it is not the authority boundary: tool exposure and every external effect are still checked against the platform's pinned grants and approval state.

Agents that require company knowledge have a second deterministic boundary. They stop before model generation when no acceptable passage is available, and a deterministic citation check prevents an uncited answer from being recorded as successful. That check proves that the answer names a reference issued for the run; it does not prove that every claim is semantically faithful. Human review and the governed evaluation layer remain responsible for that higher-order judgment.

Every real change waits for a named person

When a workflow needs to actually change something outside Project Synapse — open a new work item, update an incident — that step always pauses for a person to review it in an approvals inbox first. They see what's being proposed, the reasoning behind it, and how confident the recommendation was. They can approve it as-is, edit it before approving, or reject it. Nothing executes until they decide, and every one of those decisions is recorded: who decided, what they decided, and when.

Those decisions don't just sit in a table that someone could quietly edit later. Each one is written to an append-only record where every entry is cryptographically linked to the one before it, so if an entry were changed or removed after the fact, the break shows up rather than passing unnoticed. Today that record covers the workflow steps themselves and the approval decisions made around them.

The approvals inbox — recommendations and external writes wait here for an explicit human decision.

Nothing runs anonymously

Every run is permanently tied to the signed-in person who started it. Every approval records the named person who made the call. And when an agent reads from a system like ServiceNow or Azure DevOps, it connects with dedicated sealed credentials an administrator deliberately set up for that connection — never anyone's personal login. All of that is true today.

Underneath that sits a defined model of who can do what. The platform separates the person who builds an agent, the person who operates it, the person who approves a change, and the person who audits what happened — and two of those separations are deliberately hard: whoever authored a change can never be the one who approves it, and the administrator who runs the platform is never also the auditor who reviews it. That model is written into the platform's own tests and held in place by them today; turning it into a live check on each request is part of the identity rollout described next.

Where the design goes next follows SAP's own doctrine rather than inventing a new one. When a person runs an agent interactively against a system like SAP, the call is designed to carry that person's own identity — so the target system enforces the roles they already have, and its audit trail shows the real person. An approved change is designed to execute under the name of the person who approved it, so accountability sits with the decision. And background runs are designed to use a dedicated identity per agent — never one shared account — so a security team can review each agent's access on its own, exactly as it would review a person's. None of that is live yet; it is the stated design direction, and the record-keeping above is the foundation it builds on.

Background runs answer to a named sponsor

A scheduled automation runs when nobody is watching — which is exactly when "on whose authority?" matters most. What follows is design direction, not current behavior: every scheduled automation is anchored to a named human sponsor, and the sponsor's permissions are re-checked every time the schedule fires, not just once when the schedule was created.

In that design, if the sponsor leaves the organization or loses access, the schedule stops rather than running on stale authority, and an administrator reassigns it to a new sponsor. The automation never inherits anyone's personal credentials, so nothing quietly breaks — or quietly keeps running — when a person departs. Automations that run for months on the authority of someone long gone are a known failure mode of workflow tools; this design is built to make that impossible.

One agent, many runs

Two runs of the same agent can happen at once today, and they are fully isolated from each other: each has its own permanent record and its own reserved budget, and neither can see or disturb the other. The design direction adds one control on top — a per-agent limit for agents that must never run twice at once, such as one that reconciles state in an outside system. A second start would then wait or be refused with the reason stated, rather than racing the first.

Nothing happens twice by accident

Connections to outside systems occasionally hang or time out. Project Synapse keeps a record of every action it has already completed, so if a request gets resent — because a connection dropped and something retried it — it recognizes the duplicate and doesn't repeat the change. In the rare case where a request drops in the middle and it's genuinely unclear whether it went through, Project Synapse doesn't guess: it flags that one action for a person to check, rather than risking a silent duplicate or a silent failure.

Credentials are sealed

The usernames, passwords, and access tokens used to connect to your systems are encrypted before they're ever stored. Nobody — including the agents themselves — can retrieve or view them again once entered; from that point on, you can only overwrite them with new ones. They never appear in an error message or a log line.

Access is also compartmentalized. Each part of the platform can ask only for the specific credentials on its own list — and the background scheduler's list is empty, so it can request no stored credential at all. The same sealed-credential design is built for Azure managed identity and Key Vault, so that in a company's own cloud the platform's services would authenticate as themselves, with no stored password to leak.

Every run leaves a full record

Each time an agent runs, Project Synapse keeps what went in, what came out, and — if it consulted uploaded reference material — the bounded passages issued to the model as numbered references. The run record shows the corresponding document, pack, and passage number, together with the passage that was issued to the model for that run, as plain text, to anyone who may see the run. The roles that may read pack documents (PlatformAdmin, AgentBuilder and Auditor) see an Open document link on any run they may see; it opens the cited document for PlatformAdmin, and does not open it yet for AgentBuilder and Auditor. In the support chat, a person can also open a document that their own answer cited, from that answer's source page. Other roles see the passage. When an agent consults an advisor model, each consult's question and advice are recorded, and only the run's owner and administrators can read them. None of that is a black box after the fact, and it does not overclaim that every issued passage influenced the answer.

Built for your environment, not yet deployed in one

Project Synapse is designed so that a company can run it in its own environment, and parts of that are built: a background worker for workflow steps, a scheduler, a secret provider for Azure Key Vault, and an Azure deployment design written as code and checked. None of that is set up for a company yet. The Azure design is not provisioned, the Key Vault provider has never been used against a real vault, and no company deployment exists today.

Each deployment chooses one model route profile. One of them, the "local" profile, sends the model calls of approved users to a model server the deployment names. Today it takes text only, and agents with connector tools cannot run on it. Project Synapse does not verify where that server runs: "local" is a declaration by whoever operates the deployment, made by choosing the profile. Every profile, this one included, is approved for public data only.

The hosted demo does not use the "local" profile. There, approved users reach four cloud model routes and everyone else gets the mock model.

Questions worth asking any AI platform

• Can the AI make changes to your systems directly, or does a person have to approve first?
• Where does your data actually go once you upload it?
• If something changes in one of your systems, who approved it — and is there a record?
• When the AI acts in one of your systems, whose name is on the action — a dedicated identity set up on purpose, or one shared account used for everything?

Project Synapse's answer to every one of these is built into how the platform is put together, not written on a policy page that could be changed later.