DEV Community: Der Sascha

If You Still Print and Scan Contracts in 2026, That’s a Security Bug

Der Sascha — Mon, 16 Mar 2026 11:16:23 +0000

In almost every company I visit, I still see the same scene: someone prints a contract, signs it with a pen, walks it over to a manager for a second signature, then scans it back in and sends a PDF around by email. Nobody really questions it, because “we’ve always done it that way”.

In 2012, that was normal. In 2026, I’d call it a security bug.

Not because paper is evil, but because the whole print–sign–scan workflow lives outside the security and compliance world you’ve already invested in. It’s hard to reconstruct who saw what, when. Copies land in places nobody tracks. And while you spend a lot of time and money hardening Microsoft 365 – Entra ID, Conditional Access, DLP, retention – one of your most important processes, signing agreements, is often running as a side quest next to it.

In this post I want to explain why I see it that way and why Microsoft 365 eSignature is not just a “nice convenience feature”, but a real security and compliance upgrade.

What actually happens when you print and scan

Let’s be honest about what your paper signing flow really looks like.

It usually starts in some system – ERP, CRM, DMS, whatever. Someone exports a contract as a PDF and saves it somewhere: on the desktop, in a random file share, in a personal OneDrive folder, wherever they have muscle memory.

They print it. From that moment on, you have a physical copy lying around: on the printer, on a desk, in a stack of “I’ll deal with this later”. Nobody knows exactly how many people walk past it or glance at it.

Then come signatures. The first person signs, the second is hunted down in the hallway, maybe there’s a last-minute change, so the whole thing is printed again, re-signed, re-scanned. At the end, the contract hits a scanner – often a shared multi‑function device that “belongs” to no one. The device drops a PDF into some generic scan folder or sends it via email from a technical SMTP account.

From there, the file goes on tour: legal, finance, the customer, internal stakeholders. Everyone saves their own copy. Some people forward it, some print it again. Six months later, when you try to reconstruct who saw which version and who signed what, you end up doing email archaeology and digging through files named final_contract_v7_signed_scan.pdf.

Formally, the process might still be “okay enough” to get by. But from a security and compliance perspective it’s a mess: uncontrolled digital copies, at least one physical copy, and at best a fuzzy audit trail.

What changes with Microsoft 365 eSignature

With Microsoft 365 eSignature, you move that signing flow into an environment that already knows a lot about your users and your documents:

who the user is (Entra ID identity),
which tenant they belong to,
which policies apply (MFA, Conditional Access, DLP, retention),
and where content is supposed to live.

Instead of loosely connected PDFs and scans, you get a tracked signing workflow:

a clear request that is initiated from within Microsoft 365,
recipients that are real identities (internal Entra users or properly onboarded guests),
and an audit trail that sits inside your existing compliance boundaries.

On the practical side, that means:

far fewer “Scan_0001.pdf” zombies in random mailboxes,
no guessing which PDF is actually the final one,
a much cleaner story for your DPO and your auditors.

Screenshot 1: Sending a request inside Microsoft 365

This is where a visual helps. If you open the Microsoft adoption page for eSignature, you can see how the “send for signature” experience is meant to look directly inside Microsoft 365.

In your blog, this is a good place to show a screenshot like:

a real eSignature send dialog in Word, Outlook or SharePoint,
with a document already selected, recipients added and fields configured.

The point of that image is simple: signing doesn’t start on a printer anymore – it starts where the document already lives, inside Microsoft 365.

Why I call print–sign–scan a security bug

Security is not just about crypto and fancy products. It’s also about how easy it is for normal people to accidentally do the wrong thing.

The classic print–sign–scan flow makes it trivial to do things you don’t actually want:

leave sensitive contracts on shared printers,
store “final” versions in personal file locations,
forward PDFs from unmanaged devices or even private email accounts,
lose track of which copy is the one that matters.

You don’t need a malicious insider for this to be a problem. Normal, well‑meaning people create unnecessary attack surface simply because the process is messy and unstructured.

When you move the same use case into Microsoft 365 eSignature, you don’t instantly become perfectly compliant. But you do something important:

you anchor signing in your identity system (Entra ID),
you reuse policies you already have (MFA, Conditional Access, DLP),
and you cut down the number of uncontrolled copies by design.

For me, that’s the difference between “we sort of manage” and “we are actively reducing attack surface”.

Where Microsoft 365 eSignature fits in the real world

I’m not saying Microsoft 365 eSignature replaces every signing solution on the planet. There are absolutely scenarios where a specialised provider like Adobe Acrobat Sign or DocuSign still makes more sense – for example:

very complex external signing chains,
highly regulated cross‑border scenarios,
or very specific legal requirements in certain industries or jurisdictions.

But there is a huge middle ground that looks the same in many organisations:

internal HR flows (contracts, policy acknowledgements, consent forms),
standard customer contracts and renewals,
smaller vendor agreements,
one‑off approvals and sign‑offs.

For that space, the combination of Microsoft 365 + eSignature is almost too obvious:

you already create and store documents there,
your employees already authenticate with Entra ID,
you already pay for the platform and its security features.

Enabling eSignature doesn’t mean introducing yet another tool with its own identity silo. It means attaching a structured signing experience to something you’ve already secured.

This makes it obvious that signers are not dealing with some random scan attachment, but a structured flow with clear steps.

How I’d approach this as a security or IT owner

If I were responsible for security or IT in a mid‑sized company, I wouldn’t treat signing as a background chore anymore. I’d do a one‑time mapping of the main signing flows:

Which flows are internal (HR, internal approvals)?
Which flows hit customers or partners?
Which flows are legally critical vs. “nice to have on record”?

Then I’d split them into two buckets:

high complexity / high risk – this is where a specialised provider might remain the best option,
high volume / moderate complexity – this is where Microsoft 365 eSignature is a very strong default.

For that second bucket, I’d explicitly flip the default:

“If this scenario can run through Microsoft 365 eSignature, that’s what we do. Printing and scanning is the exception, not the standard.”

That change alone doesn’t transform your entire security posture overnight, but it nudges a huge amount of day‑to‑day work into a safer, more traceable pattern. And it gives you a far cleaner story when someone asks:

Who approved this?
When exactly did they sign?
How long do we keep the signed version?
What happens if we need to prove this in front of an auditor or a regulator?

This is the picture you want in people’s heads when they think about “how signing works here” – not a pile of PDFs in someone’s mailbox.

Conclusion: stop treating signatures as a side quest

Print–sign–scan survived for a long time because it “kind of worked” and everyone knew how to use a printer. But in 2026, when you’re already investing heavily into identity, cloud security and compliance, it doesn’t make sense to run a core business process on the side, disconnected from all of that.

Taking Microsoft 365 eSignature seriously means treating signing like any other critical process:

bound to real identities,
protected by the policies you already have,
and visible in an audit trail you can actually explain.

That’s why I’m comfortable calling the old print–sign–scan approach a security bug in 2026. Not because it never worked, but because there’s now a much better default available – and choosing not to use it is, in many environments, a conscious decision to accept more risk than you need to.

MCP Is Not Magic – It’s Just a Cleaner Way to Admit You Need an Orchestrator

Der Sascha — Sun, 15 Mar 2026 11:15:59 +0000

Every few months there is a new framework that supposedly “changes everything” about how we build AI systems.

Right now, MCP and Foundry are in that spotlight.

If you read some of the marketing posts, you get the impression that MCP is a kind of magic dust you sprinkle on your agents and suddenly everything is more powerful, safer and easier to manage.

I don’t buy that.

I like MCP. I like Foundry. But not because they are magic.

MCP is essentially a cleaner way to admit that you need an orchestrator.

In this post I want to unpack what that means, using a very concrete example: an agent that understands the gap between SAP / SuccessFactors and Entra ID, and reports identity drift back to you.

1. The reality before MCP: ad-hoc glue everywhere

Before MCP/Foundry, most “agents” in companies looked like this:

a chat UI somewhere (Teams bot, web frontend, Slack app),
a backend service written in whoever’s favourite language,
a bunch of custom HTTP endpoints or SDK calls to systems like SAP, Entra, Jira, Confluence, ServiceNow, …
some prompt engineering and an LLM call glued on top.

If you were disciplined, you at least hid those systems behind a minimal set of APIs:

getUserProfile(email) instead of “call SAP, then Graph, then some random DB”,
createTicket(summary, details) instead of “POST to Jira with a half-baked payload”.

If you weren’t, your agent prompt probably contained a free-form explanation like:

“When you need SAP data, call this URL with this payload. When you need Entra data, call this other URL…”

It worked, but it was fragile and hard to reason about.

2. What MCP actually gives you

MCP (Model Context Protocol) formalises something many of us were already doing intuitively:

you describe tools in a machine-readable way,
you keep business logic and credentials on your side,
the agent gets a clean menu of what it can do and how to call it.

Instead of informal “when you need SAP…” paragraphs, you get structured capabilities like:

sap_list_users(limit)
entra_list_users(limit)
report_mismatches(filter)

Foundry builds on top of this by giving you a consistent runtime, hosting and lifecycle around those tools.

None of that is magic. It’s just good software engineering discipline encoded into a protocol and a platform.

3. Example: A Sync Insights agent on MCP/Foundry

Let’s make this less abstract.

Imagine you want an agent that can answer questions like:

“Show me active SAP employees who don’t have an Entra account.”
“Where do department attributes differ between SAP and Entra?”
“Which Entra accounts look like they should have been deprovisioned already?”

Under the hood you need three things:

an SAP/SuccessFactors API client,
an Entra ID client (Microsoft Graph),
a bit of logic that compares both and reports mismatches.

With MCP/Foundry, you expose this as a small set of tools instead of one giant do-everything endpoint.

3.1. Tool-level view

The tools might look like this in conceptual terms:

sap_list_users(limit, departmentFilter) – returns a normalised list of SAP users.
entra_list_users(limit, departmentFilter) – returns a normalised list of Entra users.
report_mismatches(scope) – returns a summary of differences between both sides.

The Sync Insights agent doesn’t need to know how SAP authentication works or which Entra Graph scopes you requested. It only “sees” the tools.

Behind those tools lives your service code – written in Node, .NET, whatever you like – that you can test like any other backend.

3.2. Why this is better than pure prompt glue

The benefits are subtle but important:

Discoverability : tools are explicit. You can introspect them, generate docs, reason about what the agent can and cannot do.
Security : credentials stay in your server. The agent never sees SAP passwords or client secrets.
Reusability : the same toolset can be used by multiple agents, CLI tools, scripts.
Testability : you can unit test report_mismatches() without an LLM in the loop.

You could have built all of this without MCP, of course. But MCP gives you a shared language and wiring for it.

4. Where Foundry adds value

Foundry is essentially a home for your MCP tools and agents.

From my perspective, its value in this story comes from:

standardised hosting for your agents and tools (no more “where is that container running again?”),
configuration and environment separation (dev vs. prod, different tenants),
observability : calls, latency, errors per tool,
and a place to evolve your agents over time without rewriting everything.

For the Sync Insights agent, a Foundry setup might look like:

one Foundry project per organisation/tenant,
a tool bundle exposing SAP and Entra operations,
an “Insights” agent that knows how to combine them.

From there, you can connect different frontends:

a Teams message extension,
a simple web UI for identity admins,
scheduled runs that post reports into a channel.

5. The orchestrator question you can’t dodge

MCP and Foundry don’t change a fundamental truth about non-trivial AI systems:

Somewhere, you need an orchestrator that decides which tools to call, in which order, and with which data.

You can pretend that this logic “just happens” inside the LLM because you wrote a long prompt. Or you can admit that:

part of that orchestration belongs in the model (planning, natural language understanding),
and part of it belongs in your code (validation, retries, safety checks, state).

MCP makes that split a bit more honest: tools are first-class citizens. Foundry gives you a place to run them.

But you still have to design:

which tools an agent is allowed to use,
what a “good plan” looks like for a given workflow,
and where you want a human in the loop.

6. Where I see the sweet spot for MCP + Foundry

In my own projects, the combination of MCP and Foundry shines when:

I have to integrate multiple enterprise systems (SAP, Entra, Jira, Confluence, ticketing),
I want to keep all real credentials and complexity in a backend I own,
but I want agents to feel like they have a unified “brain” for these systems.

The Sync Insights agent is a great fit for this:

it’s cross-system by nature (HR vs. Identity),
it’s read-heavy and insight-focused (perfect for AI summarisation),
it benefits massively from being able to call multiple tools in a single conversation.

I wouldn’t use MCP/Foundry for a one-off “call this single API and return JSON” plugin – that’s overkill. But the moment you’re juggling several systems and workflows, you need an orchestrator anyway. MCP just gives that orchestrator a standard shape.

7. My take

I don’t see MCP or Foundry as magic. I see them as an honest acknowledgement that:

tool calls matter,
backends matter,
and orchestration is too important to hide in a prompt.

For scenarios like SAP ↔ Entra Sync Insights, that’s exactly what I want:

a clean set of tools that express what my backend can do,
a platform that runs them with proper observability,
and agents that are powerful because their world is well-structured – not because we believed in magic.

If you go into MCP/Foundry with that mindset, you’re less likely to be disappointed – and much more likely to build something that survives the next hype cycle.

SAP vs. Entra ID: Why Your User Sync Should Be a Product, Not a Script

Der Sascha — Sat, 14 Mar 2026 12:02:47 +0000

In a lot of organisations I talk to, the story sounds like this:

SAP (or SuccessFactors) is the source of truth for people and org structure.
Entra ID (formerly Azure AD) is the front door for apps and services.
Somewhere between them lives a “sync”.

When you ask what that sync is, you usually get one of these answers:

“We have a script for that.”
“That’s handled by a black-box connector, don’t touch it.”
“IT and HR sort it out manually when things break.”

That might have been acceptable in 2012. In 2026, with hundreds of SaaS apps behind Entra, compliance requirements and AI agents that can act on top of your identity graph, I think that mindset is dangerous.

My argument in this post is simple:

Your SAP ↔ Entra ID user sync is not a script. It’s a product.

And you should treat it like one.

1. What goes wrong when sync is “just a script”

When user sync is an invisible background job, a couple of things tend to happen:

Responsibilities are fuzzy (“Is this HR’s fault or IT’s fault?”).
There is no clear SLO (“How long until changes in SAP show up in Entra?”).
Drift accumulates silently:
departments don’t match,
people who left still have accounts,
service accounts live forever,
shadow roles are assigned and never cleaned up.
Nobody has a simple answer to “How many users are in SAP but not in Entra (and vice versa)?”.

When you then start layering things like Conditional Access, Just-in-Time access or Copilot on top of Entra, this drift turns from nuisance into real risk.

2. Thinking of sync as a product

If you treat the SAP ↔ Entra sync as a product, the conversation changes.

A product has:

a clear scope and responsible owner,
defined inputs and outputs ,
health metrics and SLOs,
and a roadmap for improvement.

In this framing, the sync product might be responsible for:

keeping core identity attributes aligned (name, department, manager, employment status),
ensuring there are no “orphaned” accounts (SAP-only or Entra-only, within agreed rules),
providing reliable data for downstream systems (RBAC, licences, security policies),
and giving HR / IT insights about drift, not just blind automation.

This is where I like the idea of an AI-assisted Sync Insights agent on top of the raw mechanics.

3. A Sync Insights agent as a first-class tool

In a previous post, I sketched an MCP-based agent that:

talks to SAP/SuccessFactors via API,
talks to Entra ID via Microsoft Graph,
compares both sides,
and returns a structured report of mismatches.

The key twist is: it doesn’t auto-fix anything. It gives you visibility.

Conceptually the flow looks like this:

The agent can answer questions like:

“Show me all active employees in SAP who have no Entra account.”
“List Entra accounts not present in SAP (excluding technical accounts).”
“Where do department attributes differ between SAP and Entra?”

Under the hood, you can structure it as a small Node/TypeScript service (or a Foundry agent) with tools like:

sap_list_users(limit)
entra_list_users(limit)
report_mismatches(filters)

From a Foundry/MCP perspective, the implementation details are less important than the principle: you expose high-level capabilities , not raw SQL or shell.

3.1. Example: computing mismatches

This is roughly what the core comparison might look like (simplified):

type SapUser = {
  userId: string;
  email: string | null;
  department: string | null;
};

type EntraUser = {
  userPrincipalName: string;
  mail: string | null;
  department: string | null;
};

type SyncMismatch = {
  type: 'MissingInEntra' | 'MissingInSap' | 'AttributeMismatch';
  sapUser?: SapUser;
  entraUser?: EntraUser;
  details: string;
};

function normalizeEmail(email: string | null): string | null {
  return email ? email.trim().toLowerCase() : null;
}

export function computeMismatches(
  sapUsers: SapUser[],
  entraUsers: EntraUser[]
): SyncMismatch[] {
  const mismatches: SyncMismatch[] = [];

  const entraByEmail = new Map();
  const entraByUpn = new Map();

  for (const e of entraUsers) {
    const emailNorm = normalizeEmail(e.mail);
    if (emailNorm) entraByEmail.set(emailNorm, e);
    entraByUpn.set(e.userPrincipalName.toLowerCase(), e);
  }

  // SAP -> Entra
  for (const s of sapUsers) {
    const emailNorm = normalizeEmail(s.email);
    let match: EntraUser | undefined;

    if (emailNorm) match = entraByEmail.get(emailNorm);
    if (!match) match = entraByUpn.get(s.userId.toLowerCase());

    if (!match) {
      mismatches.push({
        type: 'MissingInEntra',
        sapUser: s,
        details: `No Entra user for SAP userId=${s.userId}, email=${s.email}`,
      });
      continue;
    }

    const sapDept = (s.department || '').trim();
    const entraDept = (match.department || '').trim();

    if (sapDept && entraDept && sapDept !== entraDept) {
      mismatches.push({
        type: 'AttributeMismatch',
        sapUser: s,
        entraUser: match,
        details: `Department mismatch: SAP="${sapDept}" vs ENTRA="${entraDept}"`,
      });
    }
  }

  // Entra -> SAP
  const sapEmails = new Set(
    sapUsers.map(s => normalizeEmail(s.email)).filter((e): e is string => !!e)
  );

  const sapUserIds = new Set(sapUsers.map(s => s.userId.toLowerCase()));

  for (const e of entraUsers) {
    const emailNorm = normalizeEmail(e.mail);
    const upn = e.userPrincipalName.toLowerCase();

    const emailInSap = emailNorm && sapEmails.has(emailNorm);
    const idInSap = sapUserIds.has(upn);

    if (!emailInSap && !idInSap) {
      mismatches.push({
        type: 'MissingInSap',
        entraUser: e,
        details: `No SAP user for Entra UPN=${e.userPrincipalName}, mail=${e.mail}`,
      });
    }
  }

  return mismatches;
}

You can then have the agent format this into a CSV, a table in Teams, or a ticket summary – whatever your identity team prefers.

4. Where Foundry fits into this picture

Foundry (and MCP in general) gives you a more structured way to expose these tools to agents:

you describe tools like sap_list_users, entra_list_users, report_mismatches in a machine-readable schema,
you keep all credentials and real logic in your backend,
the agent orchestrates calls and presents results, but doesn’t hold secrets.

In practice, I’d see a stack like:

SAP API client + Entra Graph client (Node/TS, .NET, whatever you like),
a thin Foundry/MCP server that exposes “Sync Insights” tools,
a Foundry agent (or Copilot Studio scenario) that uses those tools to answer identity questions.

The key point is: Foundry is not the sync engine. It’s the orchestration/interaction layer on top of the engine.

5. Security trimming and guardrails

Identity data is sensitive. A Sync Insights agent should be held to the same standards as any identity admin tool.

A few guardrails I’d put in place:

Run the backend under a dedicated identity with scoped permissions:
for SAP: read-only on the relevant endpoints,
for Entra: limited Graph permissions (no Directory.AccessAsUser.All in production).
Record who asked which question and when, for auditing.
Make clear that the agent does not auto-fix anything; it only reports.
Expose “dangerous” actions (e.g. disable accounts, modify groups) via separate, more tightly controlled tools – or not at all.

The goal is to have an agent that helps you see problems early, not an unsupervised system that changes identities on the fly because a prompt asked nicely.

6. Treating sync as a product: what changes in practice?

If you accept the idea that SAP ↔ Entra sync is a product, a few concrete changes tend to follow:

You assign an owner (or small team) responsible for identity integrity between the two systems.
You define what “healthy” looks like (drift thresholds, sync latency, allowed exceptions).
You invest in observability (reports, dashboards, agents) instead of just “it runs at 3am”.
You give HR and IT a shared view of where reality and systems disagree.

Once you have that foundation, layering Foundry/MCP-style agents on top becomes a force multiplier instead of a risky experiment.

7. My take

In 2026, SAP and Entra are not going away. If anything, they’re getting tighter and more central as identity sources.

You can treat the sync between them as:

“that one script we inherited from someone who left”,
or as a small but critical product with proper attention.

If you pick the second option, things like Sync Insights agents, Foundry tools and AI-based reporting suddenly make a lot more sense – because sie sitzen auf einem Fundament, das jemand bewusst gebaut und verantwortet.

And that, in my view, is the only way to bring AI into identity management without waking up one day and realising nobody really knows who is supposed to have access to what.

Stop Feeding Copilot Everything: Where ‘Bring Your Own Data’ Should Have Hard Limits

Der Sascha — Wed, 11 Mar 2026 17:35:21 +0000

“Bring your own data” is the new magic phrase in the Copilot world. Vendors demo it as if you can just flip a switch and suddenly your AI assistant knows everything your company knows.

Technically, you can plug a lot of sources into Microsoft 365 Copilot: SharePoint, file shares, Confluence, Jira, databases, custom APIs…

The more interesting question is:

Which data should you never feed into a generic Copilot in the first place?

In this post I’ll argue for some hard limits on “bring your own data”, based on:

where Security Trimming actually works out of the box,
where you need your own guardrails,
and where the right answer is simply “No, this doesn’t go into Copilot at all.”

1. Where Copilot is naturally strong: M365 content with sane permissions

Let’s start with the part that works best:

documents in SharePoint and OneDrive,
conversations in Teams,
emails in Exchange,
tasks/plans in Planner, etc.

All of this flows into the Microsoft Graph index and Microsoft Search. When Copilot asks Graph for context, Graph enforces ACLs for the current user. If Alice doesn’t have access to a file, it doesn’t show up in her Copilot answers.

That doesn’t mean you’re done – you still need to:

stop dumping “secret CEO docs” into broad collaboration sites,
avoid overusing “Everyone except external users” on sensitive libraries,
and generally treat SharePoint as a real DMS, not a file dump.

But at least the security model is clear and enforced at the platform level.

2. Where BYO data starts to hurt: external sources without proper trimming

The story changes once you plug in external systems:

Confluence wikis,
file shares,
line-of-business apps,
databases, custom APIs…

There are roughly two ways people do this today:

Microsoft Graph connectors that index external content as externalItem.
Custom agents/plugins that call your APIs at runtime.

Both are valid. Both can be safe. Both can be incredibly dangerous if you ignore Security Trimming.

2.1. The “god mode service account” trap

A common anti-pattern looks like this:

Copilot calls a custom connector / agent.
The agent uses a technical account to query Confluence, Jira, SQL, etc.
That account can see “everything”.
The agent returns whatever it finds to Copilot, regardless of who is asking.

You’ve effectively built a very polite internal data exfiltration tool.

Queries like:

“List upcoming restructurings.”
“What are the salaries of senior engineers in Germany?”
“Show me current investigation reports.”

might not return anything in normal M365 search, but suddenly work great via Copilot – because you gave one backend user access to all of it.

3. Categories of data that should trigger a hard “why?”

Before talking about mechanics, let’s be very clear on what we’re talking about.

Whenever someone suggests “let’s bring system X into Copilot”, I’d ask:

Does this system contain any of the following?
HR & compensation data Salaries, bonuses, performance reviews, promotion decisions, layoff lists.
Legal & compliance data Investigations, incident reports, privileged legal advice, whistleblower cases.
Security-sensitive logs & configs Firewall rules, security incident logs, vulnerability reports, secrets.
Highly regulated customer data Health records, financial transaction details, anything under strict regulation.

If the answer is “yes”, I’d default to:

no generic Copilot access to that system,
or only carefully scoped, role-specific agents with explicit topic guards.

Not “never”, but “only with a very conscious design”.

4. Graph connectors: powerful, but ACLs are everything

Graph connectors extend the Microsoft Search/Copilot index to external content sources. They’re great when:

content is mostly read-only,
you can express permissions as ACLs,
and you’re okay with near-real-time instead of per-request freshness.

The security story:

you push items as externalItem into an externalConnection,
each item carries an acl array,
Graph uses that ACL when answering searches and Copilot requests.

If your ACLs are wrong, your security is wrong.

Example (TypeScript, simplified):

import fetch from 'node-fetch';

const GRAPH_BASE = 'https://graph.microsoft.com/v1.0';
const CONNECTION_ID = 'contosoConfluence';

async function getAppToken(): Promise<string> {
  // client credentials flow for your app registration
  return '<token>';
}

type SourcePage = {
  id: string;
  title: string;
  url: string;
  body: string;
  allowedUsers: string[]; // AAD IDs or UPNs
  forbiddenUsers?: string[]; // optional explicit deny list
};

export async function pushExternalItem(page: SourcePage) {
  const token = await getAppToken();

  const grantAcl = page.allowedUsers.map(userId => ({
    type: 'user',
    value: userId,
    accessType: 'grant' as const
  }));

  const denyAcl = (page.forbiddenUsers ?? []).map(userId => ({
    type: 'user',
    value: userId,
    accessType: 'deny' as const
  }));

  const item = {
    id: page.id,
    properties: {
      title: page.title,
      url: page.url
    },
    content: {
      type: 'text',
      value: page.body
    },
    acl: [...grantAcl, ...denyAcl]
  };

  const res = await fetch(
    `${GRAPH_BASE}/external/connections/${CONNECTION_ID}/items/${page.id}`,
    {
      method: 'PUT',
      headers: {
        'Content-Type': 'application/json',
        'Authorization': `Bearer ${token}`
      },
      body: JSON.stringify(item)
    }
  );

  if (!res.ok) {
    console.error('Failed to push externalItem', await res.text());
    throw new Error('graph_error');
  }
}

If you take the time to map your external permissions into these ACLs properly, Graph will do the trimming for you. If you don’t, you’re back to square one.

5. Custom agents: your backend is the security model

For live data and actions (“create ticket”, “get current balance”, “trigger deployment”), Graph connectors aren’t enough. You need an agent that calls your APIs.

The architecture looks like this:

flowchart LR
  U[User] -- ask --> C[Copilot]
  C -- call tool --> A[Agent]
  A -- HTTP --> B[Your Backend]
  B --> SYS[Systems]

Here, your backend is the entire security model.

Minimal pattern in Node/Express:

// permissions.ts
export type UserContext = {
  email: string;
  roles: string[];
  groups: string[];
};

export async function getUserPermissions(email: string): Promise<UserContext | null> {
  const entry = await directoryLookup(email); // Entra / IAM lookup
  if (!entry) return null;
  return { email, roles: entry.roles, groups: entry.groups };
}


// acl.ts
import { UserContext } from './permissions';

export type DocumentAcl = {
  allowedRoles?: string[];
  allowedGroups?: string[];
  forbiddenRoles?: string[];
};

export type ExternalDoc = {
  id: string;
  title: string;
  url: string;
  content: string;
  acl: DocumentAcl;
};

function hasAccess(doc: ExternalDoc, user: UserContext): boolean {
  const { allowedRoles, allowedGroups, forbiddenRoles } = doc.acl;

  if (forbiddenRoles && forbiddenRoles.some(r => user.roles.includes(r))) {
    return false;
  }

  if (!allowedRoles && !allowedGroups) {
    // Default: visible to all employees
    return true;
  }

  if (allowedRoles && allowedRoles.some(r => user.roles.includes(r))) {
    return true;
  }

  if (allowedGroups && allowedGroups.some(g => user.groups.includes(g))) {
    return true;
  }

  return false;
}

export function filterDocsByAcl(docs: ExternalDoc[], user: UserContext): ExternalDoc[] {
  return docs.filter(doc => hasAccess(doc, user));
}

Then your agent endpoint:

// agentHandler.ts
import { Request, Response } from 'express';
import { getUserPermissions } from './permissions';
import { filterDocsByAcl, ExternalDoc } from './acl';
import { buildAnswerFromDocs } from './rag';

interface AskRequest {
  question: string;
  userEmail: string;
}

interface AskResponse {
  answer: string;
  sources: { title: string; url: string }[];
}

function isForbiddenQuestion(question: string, userRoles: string[]): boolean {
  const lower = question.toLowerCase();

  const sensitivePatterns = [
    'salary',
    'compensation',
    'bonus',
    'layoff',
    'termination list',
    'performance review',
    'investigation',
  ];

  const isSensitive = sensitivePatterns.some(p => lower.includes(p));
  if (!isSensitive) return false;

  const privilegedRoles = ['HR', 'HR_ADMIN', 'LEGAL', 'C_LEVEL'];
  const isPrivileged = privilegedRoles.some(r => userRoles.includes(r));

  return !isPrivileged;
}

export async function copilotAgentHandler(req: Request, res: Response) {
  const body = req.body as AskRequest;

  if (!body.question || !body.userEmail) {
    return res.status(400).json({ error: 'question and userEmail are required' });
  }

  const user = await getUserPermissions(body.userEmail);
  if (!user) {
    return res.status(403).json({ error: 'unknown_user' });
  }

  // 1) Topic guard: block certain questions for non‑privileged roles
  if (isForbiddenQuestion(body.question, user.roles)) {
    return res.json({
      answer: "I’m not allowed to answer this type of question for your role.",
      sources: []
    } satisfies AskResponse);
  }

  // 2) Fetch docs from your system
  const rawDocs: ExternalDoc[] = await rawSearchDocs(body.question);
  const docs = filterDocsByAcl(rawDocs, user);

  if (docs.length === 0) {
    return res.json({
      answer: `I couldn't find any documents you are allowed to see that answer "${body.question}".`,
      sources: []
    } satisfies AskResponse);
  }

  // 3) Use an LLM to build the final answer
  const { answer, usedDocs } = await buildAnswerFromDocs(body.question, docs);

  const response: AskResponse = {
    answer,
    sources: usedDocs.map(d => ({ title: d.title, url: d.url }))
  };

  return res.json(response);
}

Two important observations:

you can say “no” at the question level (topic guard),
and you can say “no” at the data level (ACL filter).

6. A simple decision table for BYO data

Scenario	Approach	Security trimming	My default stance
Docs already in SharePoint/OneDrive/Teams	Let Graph handle it	Graph ACLs based on M365 permissions	✅ Good starting point, focus on cleaning permissions.
External wiki / KB	Graph connector	ACLs you attach per item	✅ Do it, if you can map permissions cleanly.
On‑prem file shares	File share / Azure Files connector	Connector maps existing ACLs	✅ Good bridge if moving to M365 is not trivial.
Live business data (status, metrics, actions)	Custom agent + backend API	Backend enforces roles/groups + topic guards	✅ With care; design security into the API.
HR / compensation / legal investigations	Generic Copilot access	N/A	🚫 Default “no”; only very scoped agents if really needed.

7. Guardrails I’d put in place

Independent of the technical path, I’d hard-code a few rules into any “bring your own data” story:

No global service accounts without filters If an agent uses an account that can see everything, you must filter aggressively in your backend.
Logging and auditing Log which user asked what, and which systems were queried. You don’t need to store content, but you should know when someone repeatedly pokes around sensitive areas.
Topic-level deny lists It’s okay to hard-block certain topics in generic agents (“salary”, “layoff list”, “investigation”). For those, build a separate, role-specific agent if needed.
Start with low-risk sources Bring in policies, guidelines, runbooks, KB articles first. Leave HR/Legal/Security data for last – or never.

8. Conclusion: BYO data is not about dumping everything into Copilot

“Bring your own data” for Copilot should not mean “dump every system we have into a single model and hope for the best.”

Instead, I’d frame it like this:

Use native M365 content where possible and fix your permissions.
Use Graph connectors for read‑mostly knowledge sources where you can express ACLs cleanly.
Use custom agents for live systems, but treat your backend as the security boundary and enforce roles, groups and topic guards there.
Accept that some data is better handled by dedicated, role-specific tools – not a general company-wide Copilot.

If you get those basics right, “bring your own data” stops being ein Buzzword und wird zu etwas, das deinen Kolleg:innen echte Antworten liefert – ohne, dass sie Dinge sehen, die sie nie hätten sehen sollen.

OpenClaw in 2026: Power, Risk, and How to Keep Your Self-Hosted AI Agent in Check

Der Sascha — Tue, 10 Mar 2026 06:03:26 +0000

OpenClaw is one of those projects that looks harmless in a README and very different once you’ve given it real access to your life.

From the outside it’s “just” a self-hosted AI agent:

a control plane on your own machine or VPS,
a chat interface where you “DM your assistant like a friend”,
and skills that let it work with your files, calendar, home automation, dev tools, etc.

From the inside it’s something else:

You’re effectively giving an AI a remote control for everything you can do on that system.

That’s both the point and the risk.

In this post I want to walk through how I see OpenClaw in 2026 from a security angle:

what it actually is,
why self-hosted doesn’t automatically mean “safe”,
a few concrete misconfiguration risks that have already shown up in the wild,
and some practical hardening advice – plus a couple of use cases where the trade-off is worth it.

What OpenClaw actually is (in practice)

If you strip away buzzwords, OpenClaw is:

a daemon that runs under your user account (on a server, a Mac Mini, a VM…),
a toolbox for AI agents: shell access, HTTP, file I/O, messaging, cron, browser automation, …
a chat/control surface (Telegram, Signal, Discord, web UI) to talk to that daemon,
and a skills system that wires specific workflows together.

The security model is very simple:

The agent can do anything you can do on that machine, plus whatever external APIs you wire in.

That’s powerful:

you can have an AI look through log files,
auto-generate blog drafts,
monitor services,
interact with Jira, M365, home automation, dev tools, etc.

But it’s also a clear warning sign: if you wouldn’t trust a human with your shell and API keys, you shouldn’t trust an unconstrained agent with them either.

Self-hosted ≠ automatically safe

A lot of people mentally equate “self-hosted” with “secure”.

That’s not how it works.

Self-hosted AI agents like OpenClaw remove one layer of risk:

Your control plane and context live on a machine you manage.
Data doesn’t flow through a SaaS provider’s infrastructure (beyond the LLM API you choose).

But they add another layer:

You have to harden the host yourself.
You are responsible for network exposure, API keys, file permissions, cron jobs, etc.
If you misconfigure it, there is no vendor kill switch.

The security posture of OpenClaw is basically:

As secure as the machine you run it on, and as careful as you are with its capabilities.

That can be very good – or very bad.

Common risk patterns we’re already seeing

When you look at write-ups from cloud providers and security firms around OpenClaw, a few themes show up:

1. Exposed instances on the public internet

Some people run OpenClaw on a VPS and expose the control port directly to the internet (no firewall, no reverse proxy, default config).
If there’s any bug or weak auth in the control channel, you’ve essentially opened a remote shell to anyone who finds it.

Mitigation:

keep the control plane behind a VPN / private network,
or at least protect it with a reverse proxy (nginx, Caddy) + strong auth + IP restrictions.

2. Running as root / with too-broad permissions

Running OpenClaw as root means any agent action is effectively root.
Even as a normal user, if that user has passwordless sudo or access to sensitive directories, the agent inherits that power.

Mitigation:

run OpenClaw under a dedicated, least-privilege user ,
restrict that user’s access to only what the agent really needs,
avoid passwordless sudo or broad sudoers rules tied to that account.

3. Dropping secrets and API keys directly into skills

Hardcoding API keys in skill scripts or environment without scoping them.
Giving the agent “all the keys to everything” instead of per-skill/per-service keys with tight scopes.

Mitigation:

keep secrets in a dedicated, minimal .env or secrets manager,
use different keys/tokens per service with least privilege (e.g. read-only where possible),
never give the agent access to banking, HR, or other high-risk systems unless you really know what you’re doing.

4. Over-trusting model behaviour

Prompting an LLM to “run whatever commands you think are needed” without guardrails.
Letting it auto-accept or auto-execute actions from external inputs (webhooks, emails, chat, etc.).

Mitigation:

keep a human in the loop for destructive or sensitive actions,
design skills so that the agent proposes actions, but you confirm,
log actions and review unusual commands.

Practical hardening tips for an OpenClaw deployment

If I had to summarise a baseline hardening checklist for a serious OpenClaw instance:

1. Use a dedicated user and machine

Run OpenClaw under a user (openclaw, ai-agent, …) that:
has no sudo rights,
only has access to directories you consciously allow (workspace, logs, some project folders).
Prefer a dedicated VPS or small server over your daily-use laptop.

2. Keep the control port private

Bind the control server to localhost or a private network interface.
Use a VPN (WireGuard, Tailscale) or SSH tunnelling for remote access.
If you must expose it via HTTP(S), put it behind a reverse proxy with:
HTTPS,
strong auth (OIDC, access tokens, IP allowlist),
and rate limiting.

3. Scope skills tightly

Instead of a skill that can exec arbitrary shell commands everywhere, prefer:
specific scripts for specific tasks,
limited working directories,
explicit allowlists of commands.
For external systems (Jira, M365, SAP, …), use service principals with minimal scopes.

4. Log and monitor

Log all agent-initiated commands and API calls.
Set up simple alerts for:
unusual command patterns,
high error rates,
spikes in external API usage.
Periodically review logs like you would for a CI/CD system.

5. Separate “toy” and “production”

Have a sandbox instance where you play with new skills,
and a more locked-down instance for anything that touches important infrastructure.
Don’t test experimental agents on the same machine that has access to production secrets.

Use cases where OpenClaw shines (and the security trade-offs)

Despite the risks, there are use cases where a well-hardened OpenClaw instance is worth it.

1. Personal AI ops assistant

Monitor services (via cron + curl + logs parsing),
summarise incidents,
open/triage tickets,
generate postmortems.

Security angle:

Treat it like a junior SRE with read-only access to prod metrics/logs and limited ticket/alert rights,
not like a root shell glued to a model.

2. Developer productivity hub

Generate and update documentation from your codebase,
run safe automated refactors in local clones,
help you navigate multiple repos and PRs.

Security angle:

Give it access only to the repos where it’s needed,
keep it away from deployment keys and secrets,
enforce human review before any change gets merged.

3. Knowledge and blog assistant

Draft posts,
aggregate notes and links,
keep track of “what did I do on project X last month?”.

Security angle:

Low risk as long as you don’t feed it sensitive docs,
perfect playground for new skills.

4. Home automation / personal life admin

Interact with Home Assistant, calendars, todo lists, shopping…
Very comfortable, but also very revealing about your private life.

Security angle:

Run it on a local machine/Mac Mini behind your home router/VPN,
think carefully before wiring in anything with cameras, locks or finances.

Concrete security ideas I’d put into config

If I were writing an OpenClaw config/skill set for myself or someone like you, I’d:

tag skills by risk level : safe, sensitive, dangerous.
require:
no confirmation for safe (read-only queries, summaries),
explicit confirmation for sensitive (writes, API calls),
two-step confirmation or even a separate instance for dangerous (anything with infra or finances).

I’d also consider:

a simple denylist of prompt topics for certain skills:
no HR/compensation data,
no copying entire password stores,
no scraping banking emails.

You don’t have to forbid everything – but a few hard “No, this agent never does that” help avoid accidents.

My take: OpenClaw is powerful, but it needs an adult in the room

OpenClaw’s promise is compelling:

your own AI agent,
on your own hardware,
with deep integrations into the stuff you actually care about.

From a security point of view, I see it as a mix of:

CI/CD system,
home lab server,
and a very curious co-worker with shell and API keys.

If you treat it that way – with:

clear permissions,
separate environments,
logging & monitoring,
and a conscious scope,

you can get a lot of value out of OpenClaw without putting your environment at unnecessary risk.

If you treat it like a toy that “just runs on the side” and can access everything, it’s only a matter of time until you shoot yourself in the foot – with or without a hyperactive agent.

Bringing Your Own Data into Microsoft 365 Copilot (Without Breaking Security)

Der Sascha — Sun, 08 Mar 2026 11:00:58 +0000

When people first see Microsoft 365 Copilot, the first questions are usually fun:

“Summarise this document.”
“Draft a reply to this email.”

Nice for demos – but not why I’m interested.

The interesting part starts when you ask Copilot things like:

“How do we deploy project Phoenix?”
“What did we decide about feature X last quarter?”
“Show me our API guidelines.”

Those answers live in your own systems: SharePoint, Confluence, Jira, custom apps, file shares. Bringing that data into Copilot is where the value is – and where you can easily break security if you’re not careful.

In this post I want to give a pragmatic overview of how to:

bring your own data into Microsoft 365 Copilot,
understand where security trimming happens,
and actively prevent certain things from being answered at all.

Code is copy‑paste‑able; adapt it to your stack.

1. Three main paths for your own data

Simplified, you have three options:

Data already in M365 SharePoint, OneDrive, Teams, Exchange – indexed by Microsoft Search/Graph out of the box.
External content via Microsoft Graph connectors Confluence, Jira, on‑prem file shares, custom data – indexed as externalItem objects.
Custom agents/plugins that call your APIs at runtime For live data and actions.

We’ll go through each with one question in mind: who decides what the user is allowed to see?

2. Data already in M365: Graph trims for you

For content living in SharePoint/OneDrive/Teams/Exchange, the flow looks like this:

Security trimming happens in Graph/Search:

Items have ACLs tied to users/groups.
Graph only returns items the current user can see.

Your job here ist „nur“:

Docs, die für Copilot relevant sein sollen, wirklich nach M365 ziehen.
Berechtigungen in SharePoint/Teams sinnvoll pflegen (keine „Everyone“-Rechte auf sensible Sites).
Nicht am Graph vorbei direkt auf Datenbanken/Storage zugreifen.

Wenn du nichts anderes tust, ist „erstmal alles in M365 ordentlich ablegen“ der wichtigste Schritt.

3. External content: Graph connectors + ACLs

Für Systeme, die nicht in M365 leben können oder sollen (Confluence, on‑prem shares, Legacy‑Apps), sind Microsoft Graph connectors das Mittel der Wahl.

Ein Connector:

zieht oder erhält Items aus einem externen System,
legt sie als externalItem in einer externalConnection im Graph ab,
und versieht sie mit einer acl, die Security Trimming steuert.

3.1. Connection anlegen

// src/graphConnection.ts
import fetch from 'node-fetch';

const GRAPH_BASE = 'https://graph.microsoft.com/v1.0';

async function getAppToken(): Promise<string> {
  // Implement client credentials flow for your app registration
  // return access token with ExternalConnection.ReadWrite.All etc.
  return '<token>';
}

export async function createExternalConnection(connectionId: string, name: string, description: string) {
  const token = await getAppToken();

  const res = await fetch(`${GRAPH_BASE}/external/connections`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Bearer ${token}`
    },
    body: JSON.stringify({ id: connectionId, name, description })
  });

  if (!res.ok) {
    console.error('Failed to create connection', await res.text());
    throw new Error('graph_error');
  }
}

3.2. Items mit ACLs pushen

Angenommen, du ziehst Seiten aus Confluence und bekommst:

type SourcePage = {
  id: string;
  title: string;
  url: string;
  body: string;
  allowedUsers: string[]; // AAD IDs oder UPNs
  forbiddenUsers?: string[]; // optional: explizite Ausschlüsse
};

Du kannst das in ein externalItem mit acl mappen:

// src/graphItems.ts
import fetch from 'node-fetch';

const GRAPH_BASE = 'https://graph.microsoft.com/v1.0';
const CONNECTION_ID = 'contosoConfluence';

async function pushExternalItem(page: SourcePage) {
  const token = await getAppToken();

  const grantAcl = page.allowedUsers.map(userId => ({
    type: 'user',
    value: userId,
    accessType: 'grant' as const
  }));

  const denyAcl = (page.forbiddenUsers ?? []).map(userId => ({
    type: 'user',
    value: userId,
    accessType: 'deny' as const
  }));

  const item = {
    id: page.id,
    properties: {
      title: page.title,
      url: page.url
    },
    content: {
      type: 'text',
      value: page.body
    },
    acl: [...grantAcl, ...denyAcl]
  };

  const res = await fetch(
    `${GRAPH_BASE}/external/connections/${CONNECTION_ID}/items/${page.id}`,
    {
      method: 'PUT',
      headers: {
        'Content-Type': 'application/json',
        'Authorization': `Bearer ${token}`
      },
      body: JSON.stringify(item)
    }
  );

  if (!res.ok) {
    console.error('Failed to push externalItem', await res.text());
    throw new Error('graph_error');
  }
}

Wichtig:

Security Trimming hängt an dieser ACL. Wenn hier Mist steht, sieht Copilot denselben Mist.
„Forbidden“‑User kannst du mit accessType: 'deny' explizit ausschließen (je nach Szenario sinnvoll).

Ab dann behandelt Microsoft Search/Copilot diese Items wie native Inhalte – natürlich nur, wenn du sie im Copilot‑Scope aktiviert hast.

4. Custom Agents: Live-Daten mit eigenem Backend

Connectors sind super für „Was wissen wir?“‑Fragen. Für „Was ist gerade der Status?“ oder „Leg ein Ticket an“ brauchst du eine HTTP‑Schnittstelle, an die Copilot Tools/Agents Aufrufe schicken können.

Architektur:

Hier liegt Security Trimming komplett bei dir.

4.1. User-Kontext und Rollen

// src/permissions.ts
export type UserContext = {
  email: string;
  roles: string[]; // e.g. ['EMPLOYEE', 'HR', 'ENGINEERING_MANAGER']
  groups: string[]; // e.g. ['project-phoenix', 'dept-engineering']
};

export async function getUserPermissions(email: string): Promise<UserContext | null> {
  const entry = await directoryLookup(email); // Implement: query Entra ID / your IAM
  if (!entry) return null;

  return {
    email,
    roles: entry.roles,
    groups: entry.groups
  };
}

4.2. ACL für externe Dokumente

// src/acl.ts
import { UserContext } from './permissions';

export type DocumentAcl = {
  allowedRoles?: string[];
  allowedGroups?: string[];
  forbiddenRoles?: string[];
};

export type ExternalDoc = {
  id: string;
  title: string;
  url: string;
  content: string;
  acl: DocumentAcl;
};

function hasAccess(doc: ExternalDoc, user: UserContext): boolean {
  const { allowedRoles, allowedGroups, forbiddenRoles } = doc.acl;

  if (forbiddenRoles && forbiddenRoles.some(r => user.roles.includes(r))) {
    return false;
  }

  // default: visible to all employees if nothing is specified
  if (!allowedRoles && !allowedGroups) {
    return true;
  }

  if (allowedRoles && allowedRoles.some(r => user.roles.includes(r))) {
    return true;
  }

  if (allowedGroups && allowedGroups.some(g => user.groups.includes(g))) {
    return true;
  }

  return false;
}

export function filterDocsByAcl(docs: ExternalDoc[], user: UserContext): ExternalDoc[] {
  return docs.filter(doc => hasAccess(doc, user));
}

4.3. Agent-Endpoint mit Trimming und Query-Guard

Jetzt der eigentliche Handler, den Copilot aufruft:

// src/copilotAgent.ts
import { Request, Response } from 'express';
import { getUserPermissions } from './permissions';
import { searchSystemDocs } from './systemDocs';
import { buildAnswerFromDocs } from './rag';

interface AskRequest {
  question: string;
  userEmail: string;
}

interface AskResponse {
  answer: string;
  sources: { title: string; url: string }[];
}

// Simple guard against disallowed topics
function isForbiddenQuestion(question: string, userRoles: string[]): boolean {
  const lower = question.toLowerCase();

  // Example: HR-only topics
  const sensitivePatterns = [
    'salary',
    'compensation',
    'layoff',
    'termination list',
    'performance review'
  ];

  const isSensitive = sensitivePatterns.some(p => lower.includes(p));

  if (!isSensitive) return false;

  // Only allow HR / C-level roles to ask these topics
  const privilegedRoles = ['HR', 'HR_ADMIN', 'C_LEVEL'];
  const isPrivileged = privilegedRoles.some(r => userRoles.includes(r));

  return !isPrivileged;
}

export async function copilotAgentHandler(req: Request, res: Response) {
  const body = req.body as AskRequest;

  if (!body.question || !body.userEmail) {
    return res.status(400).json({ error: 'question and userEmail are required' });
  }

  const user = await getUserPermissions(body.userEmail);
  if (!user) {
    return res.status(403).json({ error: 'unknown_user' });
  }

  // 1) Block certain topics for non-privileged roles
  if (isForbiddenQuestion(body.question, user.roles)) {
    return res.json({
      answer: "I’m not allowed to answer this type of question for your role.",
      sources: []
    } satisfies AskResponse);
  }

  // 2) Query docs with ACL
  const docs = await searchSystemDocs(body.question, user);

  if (docs.length === 0) {
    return res.json({
      answer: `I couldn't find any documents you are allowed to see that answer "${body.question}".`,
      sources: []
    } satisfies AskResponse);
  }

  // 3) Build answer via LLM
  const { answer, usedDocs } = await buildAnswerFromDocs(body.question, docs);

  const response: AskResponse = {
    answer,
    sources: usedDocs.map(d => ({ title: d.title, url: d.url }))
  };

  return res.json(response);
}

Damit hast du zwei Ebenen von Schutz:

Topic Guard : bestimmte Fragen werden für normale Rollen gar nicht erst beantwortet.
ACL-Filter : selbst wenn die Frage erlaubt ist, kommen nur Dokumente durch, deren ACL zum User passt.

5. Decision table: which path to use when

Scenario	Recommended path	Security trimming
Docs already in SharePoint/OneDrive/Teams	Native M365 (Graph)	Graph enforces ACLs; keep SharePoint/Teams permissions tidy.
External wiki / KB (Confluence, CMS) with mostly read-only content	Graph connector	You attach ACLs per item (`acl`); Graph trims based on user token.
On-prem file shares	File share / Azure Files connector	Connector maps original ACLs to AAD identities; Graph handles trimming.
Live line-of-business data (status, metrics, actions)	Custom agent + backend API	Your backend enforces roles/groups + topic guards before every call.
Highly sensitive HR/legal data	Separate, role-specific agents or no Copilot access	Explicitly exclude from generic agents; only scoped tools for HR/legal.

6. Guardrails I’d put in place

Unabhängig vom Weg würde ich ein paar Regeln fest einbauen:

Kein God-Mode-Service-Account ohne weiteren Filter Wenn ein Agent mit einem Konto liest, das alles sieht, brauchst du zwingend ein ACL-Filter im Backend (wie oben).
Logging Logge (mindestens intern), welcher Agent für welchen User welche Systeme abgefragt hat – nicht unbedingt den kompletten Content, sondern Metadaten.
„No-go“-Daten explizit ausschließen Es ist okay zu sagen: „Bestimmte HR-/Legal- oder Security-Daten tauchen in Copilot nie auf.“ Bau diese Ausschlüsse bewusst ein.
Start small Lieber zwei gut abgesicherte Datenquellen als zehn halbgar integrierte.

7. Fazit

„Bring your own data“ für Microsoft 365 Copilot ist kein einziger Schalter, sondern eine Reihe von Entscheidungen:

Was gehört in M365 selbst?
Was wird über Graph Connectors indexiert?
Was braucht einen eigenen Agenten, der live mit Systemen redet?
Und wo sagen wir bewusst: „Das bleibt außerhalb der Reichweite von Copilot“?

Wenn du jede dieser Entscheidungen mit Security Trimming im Kopf triffst, kann Copilot viel näher an das kommen, was du in Meetings ständig hörst: „Frag doch mal jemanden, der sich auskennt.“ Nur dass „jemand“ diesmal ein Agent ist, der deine Daten kennt – aber nicht mehr, als er kennen darf.

Orchestrating SAP and Entra ID with MCP: A Practical Sync & Insights Agent

Der Sascha — Sat, 07 Mar 2026 17:00:46 +0000

In many enterprises, SAP (especially SuccessFactors) is still the source of truth for people and org data, while Entra ID (formerly Azure AD) is the front door for apps and services.

Bridging both worlds is usually done with brittle custom scripts, point-to-point sync jobs, or black-box connectors that are hard to debug.

In this post I will show how to use the Model Context Protocol (MCP) as a thin orchestration layer between SAP and Entra ID:

to compare what exists in both systems,
to generate a delta report ,
and to provide safe hooks for remediation (tickets, follow-ups) – without giving an agent god-mode access.

I will keep it concrete and code-backed, not just architecture diagrams.

1. What we want to achieve

The goal is a small MCP server that exposes tools like:

sap_list_users – fetch users from SAP/SuccessFactors
entra_list_users – fetch users from Entra ID
report_mismatches – compute and return deltas:
users in SAP but not in Entra
users in Entra but not in SAP
users with mismatched attributes (e.g. department, manager)

An LLM/agent (Copilot or any MCP-aware client) can then ask:

“Check if there are mismatches between SAP and Entra ID for the Engineering department and give me a summary plus CSV.”

The agent does the orchestration, but all hard security and connectivity lives in your backend, not in the model.

2. High-level architecture

At a high level, the setup looks like this:

The MCP server exposes tools, tools delegate to typed backend clients for SAP and Entra. The agent only sees high-level operations; it never touches raw credentials.

3. Project setup

We will build a minimal Node.js / TypeScript project:

mkdir mcp-sap-entra-agent
cd mcp-sap-entra-agent
npm init -y
npm install typescript ts-node @types/node axios
npm install @modelcontextprotocol/sdk
npx tsc --init

Folder structure:

mcp-sap-entra-agent/
  src/
    config.ts
    sapClient.ts
    entraClient.ts
    mismatches.ts
    mcpServer.ts
  .env
  package.json
  tsconfig.json

Environment (.env, never commit this):

SAP_BASE_URL="https://api.successfactors.eu/odata/v2"
SAP_USERNAME="..."
SAP_PASSWORD="..." # or OAuth token

ENTRA_TENANT_ID="..."
ENTRA_CLIENT_ID="..."
ENTRA_CLIENT_SECRET="..."

4. Configuration helper

// src/config.ts
import 'dotenv/config';

export const SAP_BASE_URL = process.env.SAP_BASE_URL!;
export const SAP_USERNAME = process.env.SAP_USERNAME!;
export const SAP_PASSWORD = process.env.SAP_PASSWORD!;

export const ENTRA_TENANT_ID = process.env.ENTRA_TENANT_ID!;
export const ENTRA_CLIENT_ID = process.env.ENTRA_CLIENT_ID!;
export const ENTRA_CLIENT_SECRET = process.env.ENTRA_CLIENT_SECRET!;

if (!SAP_BASE_URL || !SAP_USERNAME || !SAP_PASSWORD) {
  console.warn('[WARN] SAP config incomplete – SAP tools will not work until configured.');
}

if (!ENTRA_TENANT_ID || !ENTRA_CLIENT_ID || !ENTRA_CLIENT_SECRET) {
  console.warn('[WARN] Entra config incomplete – Entra tools will not work until configured.');
}

5. SAP client (SuccessFactors via OData)

// src/sapClient.ts
import axios from 'axios';
import { SAP_BASE_URL, SAP_USERNAME, SAP_PASSWORD } from './config';

export type SapUser = {
  userId: string;
  email: string | null;
  firstName: string | null;
  lastName: string | null;
  department: string | null;
};

export async function listSapUsers(limit = 500): Promise<SapUser[]> {
  if (!SAP_BASE_URL) {
    throw new Error('SAP_BASE_URL not configured');
  }

  const url = `${SAP_BASE_URL}/User?$format=json&$top=${limit}&$select=userId,email,firstName,lastName,department`;

  const resp = await axios.get(url, {
    auth: {
      username: SAP_USERNAME,
      password: SAP_PASSWORD,
    },
  });

  const results = resp.data?.d?.results ?? [];
  return results.map((r: any) => ({
    userId: r.userId,
    email: r.email || null,
    firstName: r.firstName || null,
    lastName: r.lastName || null,
    department: r.department || null,
  }));
}

6. Entra ID client (Microsoft Graph)

// src/entraClient.ts
import axios from 'axios';
import {
  ENTRA_TENANT_ID,
  ENTRA_CLIENT_ID,
  ENTRA_CLIENT_SECRET,
} from './config';

export type EntraUser = {
  id: string;
  userPrincipalName: string;
  mail: string | null;
  displayName: string | null;
  department: string | null;
};

async function getAccessToken(): Promise<string> {
  const url = `https://login.microsoftonline.com/${ENTRA_TENANT_ID}/oauth2/v2.0/token`;
  const params = new URLSearchParams();
  params.append('client_id', ENTRA_CLIENT_ID);
  params.append('client_secret', ENTRA_CLIENT_SECRET);
  params.append('scope', 'https://graph.microsoft.com/.default');
  params.append('grant_type', 'client_credentials');

  const resp = await axios.post(url, params);
  return resp.data.access_token as string;
}

export async function listEntraUsers(limit = 500): Promise<EntraUser[]> {
  const token = await getAccessToken();
  const url = `https://graph.microsoft.com/v1.0/users?$top=${limit}&$select=id,userPrincipalName,mail,displayName,department`;

  const resp = await axios.get(url, {
    headers: { Authorization: `Bearer ${token}` },
  });

  const value = resp.data?.value ?? [];
  return value.map((u: any) => ({
    id: u.id,
    userPrincipalName: u.userPrincipalName,
    mail: u.mail || null,
    displayName: u.displayName || null,
    department: u.department || null,
  }));
}

7. Computing mismatches

// src/mismatches.ts
import { SapUser } from './sapClient';
import { EntraUser } from './entraClient';

export type SyncMismatch = {
  type: 'MissingInEntra' | 'MissingInSap' | 'AttributeMismatch';
  sapUser?: SapUser;
  entraUser?: EntraUser;
  details?: string;
};

function normalizeEmail(email: string | null): string | null {
  if (!email) return null;
  return email.trim().toLowerCase();
}

export function computeMismatches(
  sapUsers: SapUser[],
  entraUsers: EntraUser[],
): SyncMismatch[] {
  const mismatches: SyncMismatch[] = [];

  const entraByEmail = new Map<string, EntraUser>();
  const entraByUpn = new Map<string, EntraUser>();

  for (const e of entraUsers) {
    const emailNorm = normalizeEmail(e.mail);
    if (emailNorm) {
      entraByEmail.set(emailNorm, e);
    }
    entraByUpn.set(e.userPrincipalName.toLowerCase(), e);
  }

  // 1) SAP -> Entra
  for (const s of sapUsers) {
    const emailNorm = normalizeEmail(s.email);
    let match: EntraUser | undefined;

    if (emailNorm) {
      match = entraByEmail.get(emailNorm);
    }
    if (!match && s.userId) {
      match = entraByUpn.get(s.userId.toLowerCase());
    }

    if (!match) {
      mismatches.push({
        type: 'MissingInEntra',
        sapUser: s,
        details: `No Entra user matching SAP userId=${s.userId}, email=${s.email}`,
      });
      continue;
    }

    // compare attributes
    const sapDept = (s.department || '').trim();
    const entraDept = (match.department || '').trim();

    if (sapDept && entraDept && sapDept !== entraDept) {
      mismatches.push({
        type: 'AttributeMismatch',
        sapUser: s,
        entraUser: match,
        details: `Department mismatch: SAP="${sapDept}" vs ENTRA="${entraDept}"`,
      });
    }
  }

  // 2) Entra -> SAP
  const sapEmails = new Set(
    sapUsers.map(s => normalizeEmail(s.email)).filter((e): e is string => !!e),
  );

  const sapUserIds = new Set(
    sapUsers.map(s => s.userId.toLowerCase()),
  );

  for (const e of entraUsers) {
    const emailNorm = normalizeEmail(e.mail);
    const upn = e.userPrincipalName.toLowerCase();

    const emailInSap = emailNorm && sapEmails.has(emailNorm);
    const idInSap = sapUserIds.has(upn);

    if (!emailInSap && !idInSap) {
      mismatches.push({
        type: 'MissingInSap',
        entraUser: e,
        details: `No SAP user for Entra UPN=${e.userPrincipalName}, mail=${e.mail}`,
      });
    }
  }

  return mismatches;
}

8. Wiring it into an MCP server

// src/mcpServer.ts
import { createMcpServer, ToolDefinition } from '@modelcontextprotocol/sdk';
import { listSapUsers } from './sapClient';
import { listEntraUsers } from './entraClient';
import { computeMismatches } from './mismatches';

const tools: ToolDefinition[] = [
  {
    name: 'sap_list_users',
    description: 'List users from SAP / SuccessFactors. Optional: limit.',
    inputSchema: {
      type: 'object',
      properties: {
        limit: { type: 'number', minimum: 1, maximum: 2000 },
      },
      required: [],
    },
    handler: async (input) => {
      const limit = input.limit ?? 500;
      const sapUsers = await listSapUsers(limit);
      return { users: sapUsers };
    },
  },
  {
    name: 'entra_list_users',
    description: 'List users from Entra ID (Azure AD). Optional: limit.',
    inputSchema: {
      type: 'object',
      properties: {
        limit: { type: 'number', minimum: 1, maximum: 5000 },
      },
      required: [],
    },
    handler: async (input) => {
      const limit = input.limit ?? 500;
      const entraUsers = await listEntraUsers(limit);
      return { users: entraUsers };
    },
  },
  {
    name: 'report_mismatches',
    description:
      'Compare SAP and Entra ID users and return mismatches (missing users, attribute mismatches).',
    inputSchema: {
      type: 'object',
      properties: {
        limitSap: { type: 'number', minimum: 1, maximum: 2000 },
        limitEntra: { type: 'number', minimum: 1, maximum: 5000 },
      },
      required: [],
    },
    handler: async (input) => {
      const sapUsers = await listSapUsers(input.limitSap ?? 1000);
      const entraUsers = await listEntraUsers(input.limitEntra ?? 2000);
      const mismatches = computeMismatches(sapUsers, entraUsers);

      return {
        totalSap: sapUsers.length,
        totalEntra: entraUsers.length,
        mismatchCount: mismatches.length,
        mismatches,
      };
    },
  },
];

async function startServer() {
  const server = createMcpServer({
    tools,
  });

  await server.listen(3000);
  console.log('[MCP] SAP/Entra agent listening on :3000');
}

startServer().catch((err) => {
  console.error('[MCP] Failed to start server', err);
  process.exit(1);
});

9. Hardening and next steps

Scope your Graph permissions carefully (no unnecessary Directory.Read.All in production).
Add logging & auditing around which user triggered which comparison.
Keep remediation (creating/updating users) as a separate, well-controlled flow.
Consider adding department filters or project keys to narrow down the comparison.

In a follow-up, you could plug this MCP server into an agent that not only generates the delta report, but also opens Jira tickets or compiles a weekly summary for your identity team.

How to Enable Microsoft 365 eSignature in Your Tenant

Der Sascha — Fri, 06 Mar 2026 11:17:28 +0000

In my last post I looked at why Microsoft 365 eSignature is interesting: you can request and collect electronic signatures directly in SharePoint, OneDrive and Word, without sending your documents off to a separate platform.

This follow-up is for a different audience:

Microsoft 365 admins,
SharePoint admins,
and technically inclined people who get asked: “Can you please turn this on for us?”

In other words: this is the “how do I actually enable this in a tenant?” post.

I’ll keep it business-friendly at the top and concrete at the bottom, with screenshots replaced by clear descriptions and some PowerShell where it makes sense.

1. What you’re enabling – in business terms

Before touching any admin portal, it helps to be able to explain in one sentence what you’re doing:

“We’re enabling a Microsoft 365 feature that lets people request and sign documents directly in SharePoint / OneDrive / Word, with usage billed via Azure.”

Key points you can use when talking to stakeholders:

No extra platform for many scenarios – signing happens where the files already live.
Existing providers can stay – if you use Adobe Sign or DocuSign, you can plug them in behind the M365 eSignature UI.
Pay-per-use via Azure – no new fixed M365 plan, but a usage-based service you can monitor and cap.
Same identity model – signers are M365 users or guests, so you stay inside your existing compliance and audit framework.

Once people are comfortable with that, you can move to the actual steps.

2. High-level architecture

Early on, I found this mental model helpful:

flowchart LR
  subgraph M365
    SP[SharePoint / OneDrive]
    W[Word]
  end

  M365 -- uses --> ESig[eSignature Service]
  ESig -- billed via --> AZ[Azure Subscription]

From the tenant’s perspective:

Users trigger sign requests from SharePoint / Word.
Behind the scenes, the eSignature service runs and bills usage to an Azure subscription.
Signed documents land back in your libraries.

3. Prerequisites checklist

Before doing anything else, make sure these boxes are ticked:

Azure subscription with a valid billing setup (credit card, CSP, etc.).
Microsoft 365 tenant with SharePoint Online and OneDrive for Business.
Office apps for Enterprise if you want the Word integration (desktop/web).
External collaboration policy that allows guests, if you plan to have external signers.

I strongly recommend doing the initial enablement in a test tenant or at least on a test site collection before you roll this out to everyone.

4. Linking Microsoft 365 to Azure pay-as-you-go

The eSignature feature is part of the broader “pay-as-you-go services for Microsoft 365”. You need to link your M365 tenant to an Azure subscription so usage can be billed.

High-level steps:

Sign in to the Azure portal as a subscription owner.
Verify that you have a subscription ready for pay-as-you-go services (or create one).
Sign in to the Microsoft 365 admin center as a global admin.
Navigate to the section for pay-as-you-go services (typically under Settings → Org settings → SharePoint / SharePoint Premium).
Choose the Azure subscription you want to link to your M365 tenant for document processing.

Once this link is in place, SharePoint/M365 can start using eSignature and other document processing features against that Azure subscription.

4.1. Verifying with PowerShell (optional)

If you like to double-check settings via script, you can use the SharePoint Online Management Shell:

# Connect to your tenant
Connect-SPOService -Url https://<your-tenant>-admin.sharepoint.com

# Check if SharePoint Premium is enabled (naming may vary by SKU)
Get-SPOTenant | Select-Object IsSharePointPremiumEnabled

# Enable SharePoint Premium if required
Set-SPOTenant -IsSharePointPremiumEnabled $true

Always cross-check the exact property names with the latest Microsoft documentation; they sometimes change between previews and GA.

5. Guest access and sharing – don’t skip this

Because eSignature uses secure share links and M365 identities, external signers need to exist as guests and be allowed to sign in.

Two places to review:

5.1. External collaboration settings (Entra ID / Azure AD)

In the Entra ID portal, go to External identities → External collaboration settings.
Confirm that guests are allowed.
Check who is allowed to invite guests (admins only, members, specific roles).
Review any domain allow/block lists – make sure you’re not blocking the domains you want to sign with.

5.2. SharePoint / OneDrive sharing policies

In the SharePoint admin center, go to Policies → Sharing.
For the tenant and for the specific sites you will use, ensure at least “Existing guests” or “New and existing guests” are allowed.
You do not need anonymous links for eSignature, and I’d recommend keeping them off for sensitive libraries.

Without this, sign requests to external people will fail in confusing ways (“link doesn’t work”, “I can’t access the document”). Better to align with your security team upfront.

6. Enabling eSignature in the M365 admin experience

With billing and guest access ready, you can finally flip the actual feature switch.

In the Microsoft 365 admin center, go to the SharePoint admin center.
Look for SharePoint Premium or content services settings.
Find the section for eSignature.
Enable eSignature for your tenant and confirm it can use the linked Azure subscription.

If your organisation already uses Adobe Sign or DocuSign and you want to keep them in the loop:

connect your Adobe/DocuSign tenant as a provider in the eSignature settings,
grant the required API permissions so M365 can orchestrate sign requests via that provider.

From a user’s perspective, they will see “Request signature” in M365; under the hood, the actual signature may still be processed by Adobe/DocuSign.

7. Where users will see eSignature once it’s enabled

After the switches are on, you can validate the setup by looking in three places.

7.1. SharePoint document libraries

Go to a test document library.
Upload a sample Word/PDF file.
Open the context menu or command bar → you should see an option like “Request eSignature” or similar.

7.2. Word (desktop / web)

Open a document stored in SharePoint/OneDrive.
Look for a “Sign” / “Request signatures” entry in the ribbon or File menu.

Note: this may depend on your Office build and licensing; make sure you test with an account that has the right SKU.

7.3. Power Automate

Open Power Automate and create a new flow.
Search for eSignature-related actions or for your provider connector (Adobe Sign, DocuSign) if you integrated one.
You should see actions to start a signing process, check status, etc.

8. A minimal end-to-end flow to prove it works

Before you tell everyone “it’s live”, I’d build at least one simple end-to-end flow to prove the whole chain.

Example:

Trigger: When a file is created in Library "Contracts/Pending"
Action: Get file metadata
Action: Start eSignature request (document = file, signers from a column or manual list)
Action: Wait until eSignature status = Completed
Action: Copy or move signed file to Library "Contracts/Signed"
Action: Post message in Teams channel "Legal" with link to the signed file

This doesn’t have to be your final production flow, but it gives you confidence that:

billing works,
guest access is configured correctly,
and your users will actually see signed files where you expect them.

9. Admin checklist before rolling out broadly

In tenant projects I like to ask a few questions before we roll eSignature out to everyone:

Do we know which document types should use M365 eSignature and which stay on specialised providers?
Have we defined who can request signatures and from which sites/libraries?
Is guest access configured in line with our security policy?
Do we have monitoring in place for Azure usage/costs for eSignature?
Do we know how to quickly disable eSignature if something unexpected happens?

Once those are answered, the technical enablement is straightforward – and you can point your colleagues to the previous article for the “why” and this one for the “how”.

Electronic Signatures in Microsoft 365: Using eSignature Without Leaving Your Tenant

Der Sascha — Thu, 05 Mar 2026 07:27:35 +0000

Watching people in 2026 still print out Word documents, sign them by hand, scan them and send them back by email feels a bit surreal. We have video calls with AI live captions, but contracts still travel as PDFs that bounce between inboxes.

For a long time the default answer was: “Just use DocuSign / Adobe Sign / whatever, upload the PDF and let people sign there.” That works. But it also means:

another platform, another login,
extra subscriptions just for signatures,
and documents leaving your Microsoft 365 environment.

Since late 2025, there’s another option that a lot of people seem to miss: Microsoft 365 eSignature. It lets you request and collect electronic signatures directly in M365 – and it can even sit on top of existing providers like Adobe Sign and DocuSign.

In this post I’ll walk through:

what M365 eSignature actually is,
what you need to use it, and where the limits are,
a simple, practical signing flow with Power Automate,
and how I’d think about security and identity when you modernise your signing process.

What Microsoft 365 eSignature actually is

eSignature is a feature in the SharePoint Premium / Microsoft 365 ecosystem that lets you:

request signatures,
sign documents,
and store the signed versions

directly inside Microsoft 365:

SharePoint document libraries,
OneDrive,
and the desktop/web versions of Word (Enterprise).

The core idea is simple:

You shouldn’t have to upload your contract to a third-party website just to get a legally valid electronic signature.

On top of that, if your company already uses Adobe Acrobat Sign or DocuSign , you don’t have to throw them away. M365 eSignature can use them as providers under the hood:

users stay in the M365 UI,
your existing eSignature provider still handles the actual signing workflow and compliance,
and you avoid a tool zoo from the end-user perspective.

Requirements and the guest-account catch

The basic requirements to use eSignature are:

an Azure subscription with billing enabled (pay-as-you-go for document processing),
Enterprise Office apps if you want to start signing directly from Word.

Pricing is usage-based; you pay per document/signature transaction. Microsoft has a dedicated pricing page for that on Learn.

There’s one important catch that the docs sometimes mention only briefly:

People who sign via M365 eSignature need to be users or guests in your tenant.

In other words:

Internal staff: no issue, they’re already in Azure AD / Entra ID.
External signers: need a guest account (B2B) to access the document and sign it.

For some organisations that’s totally fine – they already collaborate with partners via guests in Teams/SharePoint. For others, guest access is tightly locked down or historically disabled, so this becomes an organisational and security conversation before it becomes a technical one.

A simple signing flow in M365

Let’s look at a practical scenario:

“We have a contract as a Word document in SharePoint. We want it signed by one or more people. Once it’s signed, it should live in a ‘Signed Contracts’ library and relevant people should be notified.”

On a high level, the flow looks like this:

Option 1: start directly from Word / SharePoint

This is the simplest option:

Author saves the document in a specific SharePoint library.
In the UI, they choose something like “Request eSignature”.
They select signers (internal users and/or guests).
M365 eSignature sends out the sign requests and tracks completion.

The final signed document ends up back in the same place (or a configured destination), with an audit trail.

Option 2: embed it into a Power Automate process

If you want to treat signing as just one step in a longer business process, Power Automate is the natural place to glue things together.

Very simplified:

Trigger: When a file is created or modified in Library "Contracts"
Action: Get file metadata
Action: Start eSignature request (document = file, signers = metadata.Signers)
Action: Wait for eSignature status = Completed
Action: Copy signed document to Library "Signed Contracts"
Action: Post message in Teams channel "Legal" with link to signed file

Depending on your license and the eSignature provider you use (native M365 vs. Adobe/DocuSign connector), the exact actions differ, but the pattern stays the same: document in, signature request out, signed document back in, plus notifications.

Identity and security: who may see and sign what?

As soon as signatures are involved, identity and security move to the front of the stage.

A few principles I keep in mind:

1. Signatures are only as strong as your identity

The value of an electronic signature depends on:

how strong the identity verification is,
how good your audit trail is (who signed what, when, from where),
and whether you can show that the document didn’t change after signing.

Using M365 identities – including guests – is not a workaround, it’s part of that chain of trust. If you’re serious about compliance, you want signers to be tied to proper identities, not anonymous links.

2. “Can see” and “can sign” are different roles

Someone being allowed to view a file in SharePoint doesn’t automatically mean they should be allowed to sign it.

In practice it helps to distinguish:

readers (can view the document),
approvers (can give internal approval, e.g. via Power Automate approvals),
signers (can legally sign the document).

When you design your libraries and flows, it’s worth taking five minutes to map these roles to groups/permissions instead of letting “whoever can open the file” also be in the signer list.

3. Don’t build God-mode Flows

There’s a similar anti-pattern here as with Copilot connectors: using a single service account that can see and sign everything.

Where possible:

use dedicated service identities with scoped permissions (e.g. only certain libraries),
avoid giving Flows blanket rights to every contract library in the organisation,
log who requested a signature for which document and which signers were added.

It’s very easy to accidentally turn “streamlined signing” into “anyone with access to the Flow can make anyone sign anything”. You want to avoid that.

How this fits with external providers like Adobe/DocuSign

In a lot of organisations, Adobe Acrobat Sign or DocuSign are already in place for critical contracts, with legal and procurement being comfortable with their processes.

In that case, I wouldn’t see M365 eSignature as a replacement so much as a new front door:

make the user experience more consistent (requests from SharePoint/Word instead of from a separate portal),
keep signed docs in your existing SharePoint structures,
and let Adobe/DocuSign continue doing what they’re already doing well in the background.

For “lighter” internal documents, you might decide the native M365 eSignature path is enough. For high-stakes, high-risk contracts, you keep the dedicated provider and just surface it through M365.

A quick note on legal aspects

I’m not a lawyer, so this is not legal advice. But roughly:

Electronic signatures are recognised in many jurisdictions, with different levels (simple, advanced, qualified).
Which level you need depends on the type of document and local regulations.
Large providers (including Microsoft + integrated partners) typically have detailed guidance on which of their options meet which legal standards.

The practical takeaway for me:

don’t over-engineer simple internal approvals – eSignature is often good enough there,
for critical, regulated use cases, involve Legal and stay on the supported path of your chosen provider.

My take: where M365 eSignature makes sense

For me, Microsoft 365 eSignature is most interesting in three situations:

Internal agreements and routine contracts Stuff like NDAs, internal approvals, standard vendor contracts, where the main pain is the ping-pong of PDFs and email.
Teams that already live in M365 If your users spend most of their day in Teams, SharePoint and Outlook, keeping the signing flow in that world removes friction.
Organisations with a mix of needs You can use native eSignature for “lightweight” cases and still integrate your heavyweight provider for the contracts that really matter.

The main thing I’d keep in mind is the same theme that came up in my Copilot posts: identity and security are not an afterthought.

If you take the time to:

clean up who is allowed to see and sign what,
design your libraries and Flows with clear roles,
and avoid god-mode service accounts,

then M365 eSignature can turn a surprisingly stubborn part of your process – “print, sign, scan” – into something that finally fits the rest of your digital workspace.

Security Trimming with Microsoft 365 Copilot: Asking the Right Data in the Right Context

Der Sascha — Thu, 05 Mar 2026 06:10:47 +0000

The more I work with Microsoft 365 Copilot, the less I think about prompts – and the more I think about permissions.

It’s one thing to have an AI that can summarise public docs. It’s a very different thing to plug it into your company’s real data and let people ask whatever they want.

At that point, the question isn’t “Can Copilot answer this?” but:

“Should Copilot answer this – for this user – right now?”

In this post I want to talk about security trimming in the context of M365 Copilot:

what it actually means,
where people are currently cutting corners,
and how I’d implement a practical, generic pattern when you connect external systems like Confluence or custom APIs.

I’ll keep it concrete and code-backed, not just policy talk.

1. Why security trimming is not optional with Copilot

When people roll out Copilot in a hurry, the conversation often sounds like this:

“Let’s connect it to everything, then we see what happens.”
“It’s just summarising documents, how bad can it be?”

Pretty bad.

Most organisations have data that:

only a tiny group should see, or
should never be mashed together by a generic assistant.

Think of:

CEO docs: M&A plans, board minutes, confidential strategy decks, early product plans.
HR data: future layoff lists, performance reviews, salary and bonus details.
Legal and compliance content: investigations, sensitive contracts, whistleblower reports.

If your Copilot integration ignores permissions, all of that becomes a “nice” answer to:

“What are our upcoming layoffs?”
“How much does Person X make?”
“What legal issues are we currently dealing with?”

That’s not a bug, that’s a breach with extra steps.

So let’s be clear: security trimming is not a nice-to-have in Copilot land, it’s the core of whether you can safely use it on real data at all.

2. What “security trimming” actually means here

In this context, security trimming means:

Every piece of data used to answer a Copilot question must be filtered according to the current user’s identity and permissions.

There are two layers to think about:

Inside the Microsoft 365 worldWhen you use Microsoft Graph (SharePoint, OneDrive, Exchange), the platform already understands ACLs and user tokens. If you do it right, security trimming comes “for free”.
Outside Microsoft 365When you connect external systems like Confluence, Jira, SAP, databases, you are back in DIY land. You need to bring your own security trimming.

Most of the scary stories I see are from the second category.

3. How Copilot + Graph handle permissions by default

On the M365 side, the picture looks roughly like this:

flowchart LR
  U[User] --> C[Copilot]
  C --> P[Plugin / Agent]
  P --> G[Microsoft Graph]
  G --> D[(M365 Data)]

  subgraph M365
    G
    D
  end

When your plugin/agent calls Graph with a delegated user token:

Graph checks what the user is allowed to see (SharePoint, OneDrive, Teams, mailboxes, etc.).
You get back only the documents, messages and items that user has access to.

Security trimming happens at the Graph level. That’s good. You still need to be careful which scopes you request, but you’re not manually filtering file lists in your own code.

The problem starts when people think they get the same behaviour automatically for everything else.

4. The dangerous gap: external systems without trimming

As soon as you build your own HTTP connector or call third-party APIs directly from an agent, you can easily sidestep all that nice trimming.

Typical anti-pattern:

Your Copilot plugin talks to your own backend.
Your backend calls Confluence/Jira/SQL with a service account that can see everything.
You return whatever is found, regardless of who asked.

Now imagine a user who normally has no access to CEO documents asking:

“Show me all upcoming restructuring plans.”
“What salary bands do we have for senior engineers?”

If your backend happily queries everything with a technical account and returns it to Copilot, you just built a very friendly internal data exfiltration tool.

The key rule is:

Agents and connectors must treat user identity as a first-class input and enforce access checks before they ever touch external data.

5. A practical pattern: passing user context and enforcing ACLs

Let’s look at a simple pattern I like to use for external systems.

High-level flow:

Here the Mermaid code:

flowchart LR
  U[User] --> C[Copilot]
  C --> A[AskExternalData / Agent]
  A --> B[Backend]
  B --> AUTH[Auth / Directory]
  B --> EXT[External System]
  EXT --> B
  B --> C

Important pieces:

Copilot passes user context to your backend (at least an email or user ID).
Your backend calls an auth/directory service to resolve permissions (groups, roles, allowed projects).
Your backend only queries the external system for what the user is allowed to see, or filters results accordingly.

Let’s make that concrete.

5.1. API contract

Define an API where the agent sends the question plus user context:

// Request payload from Copilot plugin
interface AskExternalRequest {
  question: string;
  userEmail: string;
  projectKey?: string;
}

interface AskExternalResponse {
  answer: string;
  sources: { title: string; url: string }[];
  missingInfo: boolean;
}

5.2. Express handler with security trimming hook

// src/secureAsk.ts
import { Request, Response } from 'express';
import { getUserPermissions } from './permissions';
import { searchExternalDocs } from './externalDocs';
import { buildAnswerFromDocs } from './rag';

export async function secureAskHandler(req: Request, res: Response) {
  const body = req.body as AskExternalRequest;

  if (!body.question || !body.userEmail) {
    return res.status(400).json({ error: 'question and userEmail are required' });
  }

  try {
    // 1) Resolve user permissions from your directory/IAM
    const userPerms = await getUserPermissions(body.userEmail);
    if (!userPerms) {
      return res.status(403).json({ error: 'unknown_user' });
    }

    // 2) Search external docs WITH permissions
    const docs = await searchExternalDocs(body.question, userPerms, body.projectKey);

    if (docs.length === 0) {
      const answer = `I couldn't find any documents you have access to that answer "${body.question}".`;
      const response: AskExternalResponse = {
        answer,
        sources: [],
        missingInfo: true
      };
      return res.json(response);
    }

    // 3) Build an answer using an LLM
    const { answer, usedDocs } = await buildAnswerFromDocs(body.question, docs);

    const response: AskExternalResponse = {
      answer,
      sources: usedDocs.map(d => ({ title: d.title, url: d.url })),
      missingInfo: false
    };

    return res.json(response);
  } catch (err) {
    console.error('secureAsk error', err);
    return res.status(500).json({ error: 'internal_error' });
  }
}

5.3. A simple permission model

You can model permissions in many ways. Here’s a very simple example:

// src/permissions.ts
export type UserContext = {
  email: string;
  roles: string[];   // e.g. ['EMPLOYEE', 'HR', 'ENGINEERING_MANAGER']
  groups: string[];  // e.g. ['project-phoenix', 'dept-engineering']
};

// In reality this might talk to Azure AD, Okta, your own directory, ...
export async function getUserPermissions(email: string): Promise<UserContext | null> {
  // Placeholder: load from your IAM
  const entry = await directoryLookup(email);
  if (!entry) return null;

  return {
    email,
    roles: entry.roles,
    groups: entry.groups
  };
}

6. Implementing generic security trimming for external content

For external documents (Confluence pages, database rows, etc.) you need a way to represent who is allowed to see what.

A very generic model:

export type DocumentAcl = {
  allowedRoles?: string[];  // e.g. ['HR', 'CEO']
  allowedGroups?: string[]; // e.g. ['project-phoenix']
};

export type ExternalDoc = {
  id: string;
  title: string;
  url: string;
  content: string;
  acl: DocumentAcl;
};

function hasAccess(doc: ExternalDoc, user: UserContext): boolean {
  const { allowedRoles, allowedGroups } = doc.acl;

  if (!allowedRoles && !allowedGroups) {
    // default: visible to all employees
    return true;
  }

  if (allowedRoles && allowedRoles.some(r => user.roles.includes(r))) {
    return true;
  }

  if (allowedGroups && allowedGroups.some(g => user.groups.includes(g))) {
    return true;
  }

  return false;
}

export function filterDocsByAcl(docs: ExternalDoc[], user: UserContext): ExternalDoc[] {
  return docs.filter(doc => hasAccess(doc, user));
}

Then in your search function:

// src/externalDocs.ts
import { ExternalDoc, filterDocsByAcl } from './acl';
import { UserContext } from './permissions';

export async function searchExternalDocs(query: string, user: UserContext, projectKey?: string): Promise<ExternalDoc[]> {
  // 1) Query the external system (e.g. Confluence, SQL, custom API)
  const rawDocs = await rawSearchDocs(query, projectKey);

  // 2) Apply ACL-based filtering
  const visibleDocs = filterDocsByAcl(rawDocs, user);

  return visibleDocs;
}

High-level, the flow then looks like this:

7. Concrete example: secure Confluence connector

Let’s connect this back to Confluence, similar to my previous “Ask the Company” post.

Instead of querying Confluence with a technical account and dumping all results into an LLM, we:

resolve the user’s allowed spaces or labels,
limit the Confluence search to those spaces, or
filter pages after retrieval using ACL metadata.

In a simple setup, you might maintain a mapping like:

// src/projectSpaces.ts
const projectSpaceMap: Record<string, string> = {
  'project-phoenix': 'PHX',
  'project-orion': 'ORI'
};

export function getAllowedSpacesForUser(user: UserContext): string[] {
  const spaces = new Set<string>();

  for (const group of user.groups) {
    const spaceKey = projectSpaceMap[group];
    if (spaceKey) spaces.add(spaceKey);
  }

  // Add global "company" space for all employees if you want
  spaces.add('COMPANY');

  return Array.from(spaces);
}

Then use it in your Confluence search:

import { getAllowedSpacesForUser, UserContext } from './permissions';

export async function searchConfluenceSecure(query: string, user: UserContext): Promise<ConfluencePage[]> {
  const spaces = getAllowedSpacesForUser(user);

  const cqlParts = [`text ~ "${query.replace(/"/g, '\\"')}"`];
  if (spaces.length > 0) {
    const spaceFilter = spaces.map(s => `space = "${s}"`).join(' OR ');
    cqlParts.push(`(${spaceFilter})`);
  }

  const cql = cqlParts.join(' AND ');

  // ... same as before, but using the restricted CQL
}

Now the agent will:

only search spaces the user is mapped to,
and won’t “accidentally” surface CEO or HR spaces that live elsewhere.

8. Sensitive data you probably shouldn’t pipe through

Even with good trimming, there are categories of data I’d think twice about running through a general Copilot agent at all:

individual salary and compensation details,
future layoff or restructuring plans,
logs and reports from ongoing investigations,
deeply personal HR/health information.

A few strategies that help:

Explicitly exclude certain systems or folders from general-purpose agents.
Use separate, highly scoped agents for HR or legal, only available to specific roles.
Be careful with training data if you use logs to improve models – keep sensitive content out of those loops.

Security trimming is not only about “who can read the file”. It’s also about “which AI flows are allowed to touch it and combine it with other information”.

9. Developer checklist before you connect something to Copilot

If I had to put this into a blunt checklist, it would look like this:

Can I reliably identify the user in my backend (email, ID, token)?
Do I use delegated permissions where possible, instead of a god‑mode service account?
Where are permissions for this data actually defined (AD, custom DB, app), and do I check them?
Are there data classes I should exclude entirely from generic agents?
Do I log which agent delivered which data to which user, for auditing?
Is there a simple way to disable or limit an agent quickly if something goes wrong?

10. Closing thoughts: Copilot is only as safe as your connectors

Microsoft 365 and Graph do a lot of the heavy lifting for you on the M365 side. If you stay within that world and use delegated permissions correctly, security trimming works in your favour.

The moment you step outside – Confluence, SAP, custom APIs, databases – you’re back in your usual role: architect, not just user.

For me, the principle is simple:

If I wouldn’t give a human service account read access to all of this without restrictions, I definitely shouldn’t do it for an AI agent either.

Copilot is powerful, but it doesn’t magically know what your company considers sensitive. That’s still your job. Security trimming is the line between “useful internal assistant” and “polite data leak on demand”.

Building an 'Ask the Company' Agent in Microsoft 365 Copilot

Der Sascha — Mon, 02 Mar 2026 12:00:18 +0000

I’ve been playing more and more with Microsoft 365 Copilot lately, and one pattern keeps coming back:

The interesting part is not “answer my email”, it’s “answer questions about how our company works”.

Every organisation has the same type of question:

“How do we do this here?”
“Where is that documented?”
“Have we done this before?”

The answers usually live somewhere in Confluence, SharePoint or Teams documents. But most of that knowledge is locked behind search, folder structures and tribal memory.

In this post I want to sketch how I’d build an “Ask the Company” agent in Microsoft 365 Copilot that:

answers questions about a project,
pulls information from Confluence,
and notices when something is missing – so it can help you document it.

I’ll go through three pieces:

the architecture idea,
a simple backend with sample code (Node/TypeScript),
and how Copilot can use it as an agent.

1. The idea: “Ask the Company” inside M365

The idea is simple:

In M365 Copilot you expose a new ability: Ask the Company.
A user types: “How do we handle deployments for Project Phoenix?”
Copilot calls your own backend (“CompanyAgent API”) with the question plus user/project context.
The backend:
searches Confluence for relevant pages,
extracts the important passages,
builds an answer,
and flags when there is no or not enough documentation.
If nothing is found, the agent suggests:
creating a new Confluence page draft for this topic,
based on what the user just asked.

The agent’s role is:

Read : fetch knowledge from Confluence,
Answer : compose a clear answer for Copilot,
Learn : detect gaps and help to close them.

2. The backend: a simple Node/TypeScript example

Let’s build a minimal backend that:

exposes a /ask endpoint,
searches Confluence via REST,
and returns an answer plus a missingInfo flag.

2.1 Basic Express setup

// src/server.ts
import express from 'express';
import bodyParser from 'body-parser';
import { searchConfluence, getConfluencePageExcerpt } from './confluence';
import { buildAnswerFromPages } from './rag';

const app = express();
app.use(bodyParser.json());

type AskRequest = {
  question: string;
  projectKey?: string;
  userEmail?: string;
};

type AskResponse = {
  answer: string;
  sources: { title: string; url: string }[];
  missingInfo: boolean;
};

app.post('/ask', async (req, res) => {
  const body = req.body as AskRequest;

  if (!body.question) {
    return res.status(400).json({ error: 'question is required' });
  }

  try {
    // 1) Search Confluence
    const pages = await searchConfluence(body.question, body.projectKey);

    if (pages.length === 0) {
      const answer = `I couldn’t find any documentation about "${body.question}" in Confluence. ` +
        `It might make sense to create a page for this topic.`;
      const response: AskResponse = {
        answer,
        sources: [],
        missingInfo: true
      };
      return res.json(response);
    }

    // 2) Fetch excerpts / content
    const excerpts = await Promise.all(
      pages.map(p => getConfluencePageExcerpt(p.id))
    );

    // 3) Build an answer
    const { answer, usedPages } = await buildAnswerFromPages(body.question, excerpts);

    const response: AskResponse = {
      answer,
      sources: usedPages.map(p => ({ title: p.title, url: p.url })),
      missingInfo: false
    };

    return res.json(response);
  } catch (err) {
    console.error('Error in /ask', err);
    return res.status(500).json({ error: 'internal_error' });
  }
});

const port = process.env.PORT || 3000;
app.listen(port, () => {
  console.log(`CompanyAgent API listening on port ${port}`);
});

2.2 Confluence search and excerpts

Confluence offers a REST API that you can call with CQL (Confluence Query Language). Here’s a simplified helper module:

// src/confluence.ts
import fetch from 'node-fetch';

const CONFLUENCE_BASE_URL = process.env.CONFLUENCE_BASE_URL!;
const CONFLUENCE_USER = process.env.CONFLUENCE_USER!;
const CONFLUENCE_TOKEN = process.env.CONFLUENCE_TOKEN!;

type ConfluencePage = {
  id: string;
  title: string;
  url: string;
};

export async function searchConfluence(query: string, projectKey?: string): Promise<ConfluencePage[]> {
  const cqlParts = [`text ~ "${query.replace(/"/g, '\\"')}"`];
  if (projectKey) {
    // Example: filter by space
    cqlParts.push(`space = "${projectKey}"`);
  }
  const cql = cqlParts.join(' AND ');

  const url = new URL('/rest/api/search', CONFLUENCE_BASE_URL);
  url.searchParams.set('cql', cql);
  url.searchParams.set('limit', '5');

  const res = await fetch(url.toString(), {
    headers: {
      'Authorization': 'Basic ' + Buffer.from(`${CONFLUENCE_USER}:${CONFLUENCE_TOKEN}`).toString('base64'),
      'Accept': 'application/json'
    }
  });

  if (!res.ok) {
    console.error('Confluence search error', await res.text());
    return [];
  }

  const data = await res.json() as any;
  const results = data.results ?? [];

  return results.map((r: any) => ({
    id: r.content.id,
    title: r.content.title,
    url: `${CONFLUENCE_BASE_URL}/pages/${r.content.id}`
  }));
}

export async function getConfluencePageExcerpt(pageId: string): Promise<{ id: string; title: string; url: string; text: string }> {
  const url = `${CONFLUENCE_BASE_URL}/rest/api/content/${pageId}?expand=body.storage`;

  const res = await fetch(url, {
    headers: {
      'Authorization': 'Basic ' + Buffer.from(`${CONFLUENCE_USER}:${CONFLUENCE_TOKEN}`).toString('base64'),
      'Accept': 'application/json'
    }
  });

  if (!res.ok) {
    console.error('Confluence get page error', await res.text());
    throw new Error('confluence_error');
  }

  const data = await res.json() as any;
  const html = data.body.storage.value as string;
  const text = stripHtml(html).slice(0, 5000);

  return {
    id: data.id,
    title: data.title,
    url: `${CONFLUENCE_BASE_URL}/pages/${data.id}`,
    text
  };
}

function stripHtml(html: string): string {
  return html.replace(/<[^>]+>/g, ' ').replace(/\s+/g, ' ').trim();
}

2.3 Building an answer with an LLM

Next we need something that takes the found texts and the user’s question and produces an answer. In a real system you’d likely use RAG with vector search and a local or cloud LLM.

Here’s a minimal example assuming you have a callLLM() function somewhere:

// src/rag.ts
import { callLLM } from './llmClient';

type PageExcerpt = {
  id: string;
  title: string;
  url: string;
  text: string;
};

export async function buildAnswerFromPages(question: string, pages: PageExcerpt[]): Promise<{ answer: string; usedPages: PageExcerpt[] }> {
  const prompt = `
You are an internal documentation assistant. Answer the question based ONLY on the information below.
If the docs don’t contain a clear answer, say so.

Question:
${question}

Docs:
${pages.map((p, i) => `[#${i + 1}] ${p.title}\n${p.text}`).join('\n\n')}
`;

  const answer = await callLLM(prompt);

  // Simple heuristic: assume all pages were used
  return { answer, usedPages: pages };
}

With just these three modules you have a very simple but end‑to‑end working “Ask the Company” backend:

POST /ask receives a question,
looks up relevant docs in Confluence,
asks an LLM to summarise them,
and tells you if nothing was found.

3. Letting Copilot talk to the agent

For Copilot to use this backend, you need to expose it as a function Copilot can call – for example via Copilot Studio, a Graph connector, or an HTTP plugin-style integration.

The conceptual model is always the same:

you describe what your backend can do,
Copilot decides when to call it, based on the user’s request.

A simplified JSON description for an HTTP-style tool could look like this:

{
  "name": "companyDocumentation",
  "description": "Answer questions about internal projects by searching Confluence",
  "functions": [
    {
      "name": "askCompany",
      "description": "Get an answer to a company/project-related question from Confluence",
      "parameters": {
        "type": "object",
        "properties": {
          "question": {
            "type": "string",
            "description": "The user's question in plain language"
          },
          "projectKey": {
            "type": "string",
            "description": "Optional project/space key used to narrow the Confluence search"
          }
        },
        "required": ["question"]
      }
    }
  ]
}

From Copilot’s perspective, a conversation might look like this:

User: “How do we handle hotfix deployments for Project Phoenix?”
Copilot:
recognises that this is an internal process question,
calls askCompany with question + projectKey = "PHOENIX",
receives { answer, sources, missingInfo },
and builds a response such as:
“According to our docs: …” plus links to the sources,
or: “I couldn’t find any documentation; we should probably create some.”

If missingInfo is true, you can add a second function like:

createConfluencePageDraft(title, content)

Copilot could then propose a draft documentation page based on the question and what is known so far, so that someone can refine and publish it later.

4. What’s missing in a real implementation?

The prototype above deliberately skips a few hard but important topics:

Authentication and permissions. The agent should act on behalf of the signed‑in user, respect Confluence permissions, and make sure it doesn’t surface pages the user shouldn’t see.
Disambiguation. If the search returns multiple topics (“deployments for App A vs App B”), the agent should ask follow‑up questions instead of guessing.
Feedback into documentation. You could log which questions are asked most often and whether there’s good documentation for them – great input for documentation sprints.

But as a starting point, the pattern:

Copilot → HTTP agent → Confluence + LLM → answer + missingInfo

is already surprisingly powerful.

5. Why this is where Copilot gets interesting

The part of Microsoft 365 Copilot that excites me is not that it can summarise emails or rephrase text – that’s useful, but generic.

It gets interesting when Copilot:

has access to your systems (Confluence, Jira, SharePoint, line-of-business APIs),
can talk to your agents ,
and can answer questions like “How do we do X?” instead of just “What does the internet say about X?”.

The “Ask the Company” agent here is a sketch, but it shows the basic idea:

AI reads what you’ve already documented,
answers questions from that,
and highlights where your documentation has gaps.

That’s the kind of pattern I expect to become normal in M365 Copilot over the next years – and the kind of thing I’d rather experiment with now than wait until someone else ships it for me.

Amazfit Bip 6 vs Garmin Venu 3: Which Long-Battery Smartwatch Makes More Sense?

Der Sascha — Sun, 01 Mar 2026 07:34:13 +0000

Battery life is the reason I keep coming back to the Amazfit Bip 6. Most smartwatches want more attention than I do – daily charging, constant nudging, lots of features I don’t need. The Bip 6 is one of the first that feels like a normal watch again: you put it on and mostly forget about it.

To put that into context, I wanted to compare it to a very popular Garmin in a similar “everyday + fitness” category: the Garmin Venu 3.

This is a short, practical comparison – not a lab review.

Quick specs (high level)

Amazfit Bip 6

Focus: budget-friendly smartwatch with health tracking
Battery: roughly 7–14 days depending on usage
Display: bright colour screen, simple UI
Tracking: steps, heart rate, sleep, basic sports, GPS
Price: significantly cheaper than most Garmin models

Garmin Venu 3

Focus: health and fitness watch with smartwatch features
Battery: up to around 14 days in smartwatch mode, ~26 hours GPS (in reviews)
Display: AMOLED, very good visibility
Tracking: extensive sports profiles, advanced health metrics, strong ecosystem
Price: clearly higher, closer to premium segment

Battery life: both are in the "don’t think about it every day" club

The Bip 6 is impressive because it delivers about a week of battery life without trying too hard. If you’re not hammering GPS every day, it can push towards two weeks. That means you charge it when you notice it’s low – not as a daily ritual.

The Venu 3, like most modern Garmins, also does very well here. Reviews talk about roughly 14 days in normal smartwatch mode and plenty of GPS time for runs and rides. It’s easy to cover 1–2 weeks on a charge if you’re not doing ultra‑distance training every day.

Bottom line: both watches are in a different league from devices that barely last two days. If you care about battery, you’re safe with either – with the Bip 6 giving you that feeling at a much lower price.

Everyday use: simple companion vs. rich ecosystem

The way I see it:

Bip 6 is the “simple companion”: steps, sleep, heart rate, basic workouts, notifications. Easy enough to recommend to non‑techy people without turning into their support hotline.
Venu 3 is the “serious health tracker”: deeper metrics, better training analysis, strong Garmin Connect ecosystem, more detail for runners, cyclists and people who like to look at graphs.

If you just want to move more, sleep better and not charge your watch all the time, the Bip 6 hits a great sweet spot. If you’re training with intent and already live in Garmin land, the Venu 3 will feel more like a proper tool.

Who I’d recommend each watch to

Amazfit Bip 6 is ideal for:

people who want a low‑maintenance watch that lasts a long time,
casual users who care about steps, sleep and occasional workouts,
family and friends where you don’t want to introduce a lot of complexity.

Garmin Venu 3 is ideal for:

people who train regularly and want deeper health and performance data,
anyone already using Garmin devices (bike computer, HR strap, etc.),
users who are willing to pay more for better analytics and a mature ecosystem.

My personal bias

Personally, I’m very happy with the Bip 6 because it solves my main frustration: battery life and “too much smartwatch”. For my everyday mix of desk work, walking, light workouts and sleep tracking, it’s exactly enough.

If I ever go back into a focused training phase with clear goals (marathon, structured intervals), I’d look more seriously at a Garmin again – but I’d do it knowing that I’m paying for the extra analysis and ecosystem, not for the battery alone.

For now, the Bip 6 stays on my wrist most days, and the charger stays in the drawer a lot longer than I’m used to from other watches.