DEV Community: Der Sascha

Ubiquiti U7-LR review: WiFi 7 with strong range, but no 6 GHz

Der Sascha — Sun, 17 May 2026 17:23:09 +0000

Image: Ubiquiti / official product image

Disclosure: This article contains affiliate links. If you buy through one of these links, I may earn a small commission. The price stays the same for you.

The Ubiquiti U7-LR is one of those access points that looks like an obvious upgrade at first glance. WiFi 7, Long Range, UniFi, 2.5 GbE, PoE. If you already run UniFi at home or in a small office, it sounds like an easy yes.

I would still not buy it blindly.

The U7-LR is interesting, but there is one detail you should know before ordering it: it is a WiFi 7 access point without 6 GHz. That does not make it a bad product. It just changes what you should expect from it.

View the Ubiquiti U7-LR on Amazon

Quick verdict

The Ubiquiti U7-LR makes the most sense if you already use UniFi and want a modern access point with good range, a 2.5 GbE uplink and PoE. For a house, a larger apartment, a small office, a medical practice or a studio, it can be a very solid choice.

But if you hear "WiFi 7" and automatically expect 6 GHz, look closer. The U7-LR uses 2.4 GHz and 5 GHz. It does not have a 6 GHz radio. For many setups that is fine. For a full high-end WiFi 7 setup, a tri-band model may be the better fit.

What the U7-LR offers

According to Ubiquiti's official specifications, the U7-LR comes with:

Feature	Ubiquiti U7-LR
WiFi standard	WiFi 7
Frequency bands	2.4 GHz and 5 GHz
6 GHz band	No
5 GHz data rate	up to 4.3 Gbps at 160 MHz
2.4 GHz data rate	up to 688 Mbps
Spatial streams	5
Uplink	1x 2.5 GbE RJ45
Power	PoE
Maximum power consumption	14 W
Stated coverage	up to 160 m² / 1,750 ft²
Stated client count	300+
Mounting	Ceiling or wall

That is a strong spec sheet for this class of access point. The 2.5 GbE port matters because a regular gigabit uplink can become a bottleneck on newer access points. The 160 MHz channel width on 5 GHz is also nice to have, assuming your environment allows it.

And that last part matters. In an apartment building with lots of neighboring networks, 160 MHz is not always the best idea. More channel width can mean more interference. In a detached house or a small office, it may work well. In a crowded area, stability can be more useful than a pretty speed test.

The main catch: WiFi 7, but no 6 GHz

Image: Ubiquiti / official product image

This is the part that can cause confusion. WiFi 7 does not automatically mean that a device supports the 6 GHz band.

The U7-LR is a dual-band access point. It uses 2.4 GHz and 5 GHz. That can be a sensible choice for range and compatibility, since many devices still live on those bands anyway. But if your main reason for upgrading to WiFi 7 is 6 GHz, this is not the access point you are looking for.

I would not think of the U7-LR as the ultimate WiFi 7 playground. I would think of it as a modern UniFi access point focused on range, 5 GHz performance and everyday reliability.

Who should consider the Ubiquiti U7-LR?

The U7-LR is a good fit if you already use UniFi or want to build a UniFi network properly. The appeal is not just the access point itself. It is the UniFi Network platform around it.

Multiple SSIDs, VLANs, guest networks, roaming, band steering, client isolation and decent visibility into your network are the reasons people buy UniFi in the first place.

Good use cases include:

a house or larger apartment with a centrally mounted access point
a small office with employees and a guest WiFi network
a medical practice, agency, studio or shop
a holiday apartment where you want managed WiFi instead of a random consumer router
an existing UniFi setup that needs a WiFi 7 upgrade

In these environments, the U7-LR is more interesting than a typical consumer router. Not because it magically makes your internet faster, but because it fits into a cleaner network setup.

Who should probably skip it?

If you are looking for a router that connects directly to your DSL, cable or fiber line, the U7-LR is the wrong product. It is not a router. It is not a modem. It is an access point.

You need the rest of the network around it: a router or gateway, ideally a PoE switch or a suitable PoE injector, and some way to manage UniFi Network.

I would probably skip it if:

you do not want to use UniFi
6 GHz is a must-have for you
you do not have PoE or do not want to add it
you expect an all-in-one home router
you only need WiFi for one small room

UniFi is not impossibly complicated, but it is still more of a system than a plug-and-forget consumer box. That is either the whole point, or it is unnecessary overhead.

What customer reviews suggest

On Amazon Germany, the Ubiquiti U7-LR currently sits at around 4.2 out of 5 stars with 78 global ratings. The positive reviews mostly mention good range, stable connections and easy setup inside an existing UniFi environment.

Some reviews are very short, which is normal for Amazon. Still, the pattern is useful: people who already know UniFi seem to get along with the U7-LR quickly. Several buyers describe it as a reliable access point that does exactly what they expected.

There is also some criticism. One international review points out that the U7-LR is not a tri-band access point. Another mentions that 2.4 GHz performance did not meet expectations compared with 5 GHz. That lines up with the main caveat above: do not read "WiFi 7" and assume you are getting every premium WiFi 7 feature.

PoE and 2.5 GbE are not optional details

Image: Ubiquiti / official product image

The U7-LR is powered via PoE. In a clean network installation, that is great. One Ethernet cable handles data and power. For casual living-room use, it can be an extra hurdle.

If your switch does not provide PoE, you need a suitable PoE injector. You should also think about the uplink. The access point has a 2.5 GbE port, and ideally the switch port behind it should support 2.5 GbE as well.

That does not mean gigabit is useless. For many internet connections it is still enough. But if you are buying a WiFi 7 access point, it makes sense to check whether the rest of your network can keep up.

U7-LR or another UniFi access point?

The U7-LR is attractive if range and modern 5 GHz performance matter more to you than 6 GHz. If you already own several WiFi 7 clients with 6 GHz support and want to use that band, compare it with a proper tri-band access point before buying.

If you want to cover a house or small office with stable UniFi WiFi, the U7-LR looks like a sensible option. I would not read the "300+ clients" figure as a realistic recommendation for hundreds of active devices hammering the network at once. It is more a sign that Ubiquiti designed this for more than three phones and a TV.

My take

What I like about the U7-LR is that it knows what it is. It is not trying to be a flashy consumer router with a friendly app and a dozen marketing claims. It is a UniFi access point. That is the reason to buy it.

The Long Range name and the WiFi 7 label make it appealing, but the missing 6 GHz radio belongs in every buying decision. If you know that and it fits your setup, the U7-LR is a very interesting upgrade.

If you simply want "full WiFi 7", I would compare alternatives first.

Should you buy it?

I would buy the Ubiquiti U7-LR if:

you already use UniFi
you want a ceiling or wall mounted access point
you can provide PoE properly
you care about strong 5 GHz performance and range
6 GHz is not required for your setup

I would not buy it if you actually need a router, or if 6 GHz is the main reason you are upgrading.

View the Ubiquiti U7-LR on Amazon

Note: This article is not based on my own hands-on lab test. The assessment is based on Ubiquiti's official specifications, the Amazon product page and publicly visible customer reviews.

Teufel Rockster Air 2 review: powerful portable sound, but should you buy it over the JBL PartyBox Stage 320?

Der Sascha — Sun, 17 May 2026 17:21:45 +0000

Teufel Rockster Air 2 review: powerful portable sound, but should you buy it over the JBL PartyBox Stage 320?

Transparency note: the Amazon links in this article are affiliate links. If you buy through them, I may earn a commission at no extra cost to you. I have not run a long-term hands-on test of these speakers.

If you are looking for a serious portable Bluetooth speaker, the Teufel Rockster Air 2 and the JBL PartyBox Stage 320 sit in a similar “big party speaker” category, but they are not really built for exactly the same buyer.

The Teufel feels more like a compact mobile PA system: loud, flexible, long-lasting, and ready for microphones, instruments, small events, speeches, DJs, karaoke, and outdoor setups. The JBL is more obviously a party speaker: easier to move around, cheaper, flashier, and probably the better fit for most casual buyers.

So which one should you actually buy?

Quick verdict

If I had to recommend one speaker for most people, I would pick the JBL PartyBox Stage 320 because it is cheaper, easier to transport, has a built-in light show, and has very strong public ratings.

But if you care more about battery life, PA-style flexibility, microphone/instrument inputs, and a more professional event setup, the Teufel Rockster Air 2 is the more serious device.

Buy the Teufel Rockster Air 2 if you want a portable event speaker with long battery life and flexible inputs: check the Teufel Rockster Air 2 on Amazon
Buy the JBL PartyBox Stage 320 if you want the better value party speaker for most private parties: check the JBL PartyBox Stage 320 on Amazon

The Teufel Rockster Air 2 at a glance

The Teufel Rockster Air 2 is a portable Bluetooth event speaker with a clear focus on power and flexibility. According to the Amazon listing, it offers:

Bluetooth 5.0 with aptX, aptX HD and AAC
Up to 58 hours of battery life at medium volume
Up to 31 hours at maximum volume in Eco mode
A removable LiFePO4 battery
Microphone, instrument and AUX inputs
USB-C power bank function
35 mm tripod flange
Up to 103 dB RMS and 115 dB peak
Support for stereo setups with two Rockster Air 2 units
XLR-based linking for larger setups

That specification list tells you quite a lot about the target audience. This is not just a speaker for playing a playlist in the kitchen. It is meant for people who need loud, mobile, reasonably serious sound.

At the time I checked the listing, the Teufel Rockster Air 2 was shown at around €529.99 with a rating of around 4.5 out of 5 stars from about 100 reviews. Amazon prices and review counts can change, so treat those numbers as a snapshot rather than a fixed fact.

What I like about the Teufel Rockster Air 2

1. The battery life is the standout feature

The biggest argument for the Teufel is battery life. Up to 58 hours at medium volume is excellent for this class of speaker. Even the claimed 31 hours at maximum volume in Eco mode is impressive.

For garden parties, small events, club rooms, outdoor workouts, sports events or speeches, this matters. A speaker that still has power left after a long day is simply less annoying to own.

2. It is closer to a mobile PA than a normal party speaker

The Teufel has microphone, instrument and AUX inputs. That makes it much more flexible than a simple Bluetooth party box. You can use it for karaoke, announcements, a guitar, small performances or DJ-style setups.

That is where the Rockster Air 2 starts to justify its higher price. If you only want music from your phone, you may not need this. If you want a more flexible event speaker, it becomes much more interesting.

3. The battery is removable

A removable LiFePO4 battery is a practical long-term advantage. Batteries age. A product with a replaceable battery is usually a safer buy than one where the whole device becomes less useful once the battery degrades.

4. Better codec support than many party speakers

Bluetooth with aptX, aptX HD and AAC is a nice detail. It does not magically turn a party speaker into a studio monitor, but it does show that Teufel is paying attention to audio quality and not just loudness.

What I do not like about the Teufel Rockster Air 2

1. It is expensive

At roughly €530 at the time of checking, the Teufel is not an impulse purchase. It costs noticeably more than the JBL PartyBox Stage 320.

That price only makes sense if you actually need the Teufel’s strengths: battery life, input flexibility, PA-style use, and very loud output.

2. It lacks the fun factor of a classic party box

The Teufel looks and feels more serious. That can be a good thing, but it also means you do not get the obvious party features of the JBL: the synchronized light show, the flashy design language, and the “turn it on and the room gets a vibe” effect.

3. Transport looks less convenient than the JBL

The JBL PartyBox Stage 320 has wheels and a telescopic handle. That is boring on paper but hugely useful in real life. Big speakers are always heavier and more annoying to move than people expect.

If you move your speaker often, the JBL has a clear practical advantage.

The JBL PartyBox Stage 320 as the main alternative

The JBL PartyBox Stage 320 is the more mainstream party speaker. It is built around JBL Pro Sound, two 6.5-inch woofers, two 1-inch tweeters, a music-synchronized light show, wheels, and a telescopic handle.

According to the Amazon listing, it offers:

Up to 18 hours of battery life
10-minute quick charge for about 2 additional hours of playback
AI Sound Boost for real-time audio optimization
Built-in light show
Wheels and telescopic handle
Auracast support for connecting multiple compatible JBL speakers
Replaceable battery, sold separately

At the time I checked the listing, it was shown at around €420 with a rating of around 4.8 out of 5 stars from about 730 reviews.

Teufel Rockster Air 2 vs JBL PartyBox Stage 320

Category	Teufel Rockster Air 2	JBL PartyBox Stage 320
Approx. price at time of checking	€529.99	€420
Battery life	Up to 58 hours	Up to 18 hours
Main strength	PA-style flexibility and long runtime	Party features and value
Transport	Portable, but less comfort-focused	Wheels and telescopic handle
Light show	No	Yes
Microphone/instrument use	Stronger focus	More party-oriented
Multi-speaker setup	Stereo / XLR options	Auracast
Best for	Events, speeches, karaoke, outdoor use, semi-pro setups	Private parties, garden parties, casual users

Which one should you buy?

Buy the Teufel Rockster Air 2 if…

You should choose the Teufel Rockster Air 2 if you want a speaker that can do more than just play music loudly.

It is the better fit if:

You need very long battery life
You want microphone or instrument inputs
You might use the speaker for speeches or small events
You care about a more PA-like setup
You want a removable battery
You want to place it on a tripod
You may later expand into stereo or linked speaker setups

In that case, the higher price makes sense: Teufel Rockster Air 2 on Amazon

Buy the JBL PartyBox Stage 320 if…

You should choose the JBL PartyBox Stage 320 if you mostly want a powerful, fun and practical party speaker.

It is the better fit if:

You want the better price-performance ratio
You care about easy transport
You like the built-in light show
You mainly use Bluetooth playback
You want a proven party speaker with lots of public feedback
You do not need 50+ hours of battery life

For most buyers, this is probably the smarter purchase: JBL PartyBox Stage 320 on Amazon

My final recommendation

The Teufel Rockster Air 2 is the more serious and flexible product. It is the speaker I would look at for events, long outdoor days, microphone use, karaoke, small performances, DJ-style setups or situations where battery life really matters.

But the JBL PartyBox Stage 320 is the speaker I would recommend to most people. It costs less, is easier to move, has a more obvious party feature set, and has stronger public review momentum.

So my practical recommendation is:

Best overall for most people: JBL PartyBox Stage 320
Best for more serious mobile event use: Teufel Rockster Air 2

If your use case is “I want a great speaker for birthdays, garden parties and casual events”, get the JBL. If your use case is “I need a portable speaker that can also behave like a small PA system”, get the Teufel.

A practical SAP agent in Azure AI Foundry: OData in, governed answer out

Der Sascha — Thu, 14 May 2026 12:40:48 +0000

Most enterprise agent demos cheat at the exact point where things get interesting.

They show a nice chat window. They connect it to a toy API. The agent calls a function, gets a clean JSON response, and everyone nods. Then you try the same pattern against a real SAP system and suddenly the demo has to deal with authorization, OData filters, weird field names, data minimization, audit logs, and the uncomfortable fact that "ask the model to query SAP" is not an architecture.

This post is the version I would actually start with.

The scenario is intentionally boring: a support or operations user asks why a customer order is blocked. The agent should look up a small, approved slice of SAP data, summarize the situation, and suggest the next action. No direct database access. No model-generated OData. No magic prompt that says "be secure" and hopes for the best.

The shape of the solution

I would split the system into four parts:

Azure AI Foundry hosts the agent and handles the conversation.
The agent gets one narrow tool, for example get_order_status.
A backend service owns the SAP integration and calls an approved OData endpoint.
Identity, logging, and policy live outside the prompt.

The agent is allowed to ask a question. The tool is allowed to fetch a specific business object. The SAP layer is allowed to enforce the ugly but necessary rules.

That separation matters. If the model can invent arbitrary OData queries, it can also invent expensive, broad, or unauthorized queries. If the backend only exposes a small function with typed parameters, the blast radius is much smaller.

Example architecture

A minimal production-ish flow looks like this:

User
  -> Teams / web app / Copilot extension
  -> Azure AI Foundry agent
  -> function tool: get_order_status(order_id)
  -> integration API
  -> SAP OData endpoint / SAP BTP destination / API Management
  -> sanitized JSON back to the agent
  -> short answer + next action

I like putting Azure API Management or a small integration API between Foundry and SAP. It gives you one place for throttling, logging, allow lists, correlation IDs, and request validation. You can also swap the SAP backend later without teaching the agent a new trick.

The SAP side: keep it boring

Here is a deliberately small Python client for an SAP OData endpoint. The important part is not the HTTP library. The important part is that the caller cannot pass arbitrary filters.

# sap_client.py
import os
import requests
from dataclasses import dataclass


@dataclass(frozen=True)
class OrderStatus:
    order_id: str
    customer_name: str
    lifecycle_status: str
    delivery_block: str | None
    credit_block: str | None
    net_value: float
    currency: str


class SapClient:
    def __init__(self) -> None:
        self.base_url = os.environ["SAP_ODATA_BASE_URL"].rstrip("/")
        self.username = os.environ["SAP_TECH_USER"]
        self.password = os.environ["SAP_TECH_PASSWORD"]

    def get_order_status(self, order_id: str) -> OrderStatus:
        if not order_id.isdigit() or len(order_id) > 12:
            raise ValueError("order_id must be a numeric SAP sales order id")

        url = f"{self.base_url}/sap/opu/odata/sap/API_SALES_ORDER_SRV/A_SalesOrder('{order_id}')"
        params = {
            "$select": ",".join([
                "SalesOrder",
                "SoldToPartyName",
                "OverallSDProcessStatus",
                "DeliveryBlockReason",
                "CreditBlockReason",
                "TotalNetAmount",
                "TransactionCurrency",
            ])
        }

        response = requests.get(
            url,
            params=params,
            auth=(self.username, self.password),
            headers={"Accept": "application/json"},
            timeout=10,
        )
        response.raise_for_status()

        data = response.json()["d"]
        return OrderStatus(
            order_id=data["SalesOrder"],
            customer_name=data.get("SoldToPartyName", ""),
            lifecycle_status=data.get("OverallSDProcessStatus", "Unknown"),
            delivery_block=data.get("DeliveryBlockReason") or None,
            credit_block=data.get("CreditBlockReason") or None,
            net_value=float(data.get("TotalNetAmount", 0)),
            currency=data.get("TransactionCurrency", ""),
        )

A real implementation would probably use OAuth, principal propagation, SAP BTP destinations, or an API Management policy instead of a technical user. Fine. The same rule still applies: the agent should not build the SAP query. Your integration layer should.

The tool boundary

Now wrap the SAP client in a tiny tool function. This is also the place where I would remove fields the user should not see.

# tools.py
from sap_client import SapClient

sap = SapClient()


def get_order_status(order_id: str) -> dict:
    """Return a sanitized status summary for one SAP sales order."""
    status = sap.get_order_status(order_id)

    blocks = []
    if status.delivery_block:
        blocks.append({"type": "delivery", "reason": status.delivery_block})
    if status.credit_block:
        blocks.append({"type": "credit", "reason": status.credit_block})

    return {
        "order_id": status.order_id,
        "customer_name": status.customer_name,
        "lifecycle_status": status.lifecycle_status,
        "blocks": blocks,
        "net_value": status.net_value,
        "currency": status.currency,
    }

Notice what is missing: pricing conditions, margin, bank details, free text notes, internal partner data, and anything else that tends to leak into "just give the AI access" projects.

The model gets the minimum amount of data needed to answer the business question.

Registering the tool in Azure AI Foundry

The current Azure AI Foundry agent pattern is straightforward: define a function tool, create an agent version, send a user prompt, execute the requested function call in your app, and submit the tool output back to the model.

The sketch below follows that shape. It is not meant to be pasted blindly into production, but it shows the moving parts.

# foundry_agent.py
import json
import os

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import FunctionTool, PromptAgentDefinition, Tool
from azure.identity import DefaultAzureCredential
from openai.types.responses.response_input_param import (
    FunctionCallOutput,
    ResponseInputParam,
)

from tools import get_order_status

project = AIProjectClient(
    endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
    credential=DefaultAzureCredential(),
)

openai = project.get_openai_client()
conversation = openai.conversations.create()

get_order_status_tool = FunctionTool(
    name="get_order_status",
    description="Get the sanitized status of one SAP sales order by numeric order id.",
    parameters={
        "type": "object",
        "properties": {
            "order_id": {
                "type": "string",
                "description": "Numeric SAP sales order id, for example 4711000420",
            }
        },
        "required": ["order_id"],
        "additionalProperties": False,
    },
    strict=True,
)

tools: list[Tool] = [get_order_status_tool]

agent = project.agents.create_version(
    agent_name="sap-order-status-agent",
    definition=PromptAgentDefinition(
        model="gpt-4.1-mini",
        instructions=(
            "You help operations users understand SAP sales order status. "
            "Use the provided tool when an order id is present. "
            "Do not ask for or expose sensitive personal, payroll, banking, or margin data. "
            "Answer briefly. If a block exists, explain the likely owner and next action."
        ),
        tools=tools,
    ),
)

response = openai.responses.create(
    input="Why is sales order 4711000420 blocked?",
    conversation=conversation.id,
    extra_body={"agent_reference": {"name": agent.name, "type": "agent_reference"}},
)

tool_outputs: ResponseInputParam = []

for item in response.output:
    if item.type == "function_call" and item.name == "get_order_status":
        args = json.loads(item.arguments)
        result = get_order_status(**args)
        tool_outputs.append(
            FunctionCallOutput(
                type="function_call_output",
                call_id=item.call_id,
                output=json.dumps(result),
            )
        )

final_response = openai.responses.create(
    input=tool_outputs,
    conversation=conversation.id,
    extra_body={"agent_reference": {"name": agent.name, "type": "agent_reference"}},
)

print(final_response.output_text)

A possible answer might be:

Sales order 4711000420 is blocked because it has a credit block.
The order value is 18,420 EUR for Contoso Retail GmbH.
Next action: ask credit management to review the customer exposure before release.

That is the right level of boring. The agent did not browse SAP. It did not decide which table to query. It called one approved capability.

Add correlation IDs before you add more tools

Before I would add a second or third SAP tool, I would add tracing.

Every request should carry a correlation ID from the UI to Foundry, from Foundry to the integration API, and from the integration API to SAP or API Management logs.

# api.py
from fastapi import FastAPI, Header, HTTPException
from tools import get_order_status

app = FastAPI()


@app.get("/orders/{order_id}/status")
def order_status(order_id: str, x_correlation_id: str | None = Header(default=None)):
    if not x_correlation_id:
        raise HTTPException(status_code=400, detail="Missing X-Correlation-ID")

    result = get_order_status(order_id)

    # In production, log this as structured telemetry.
    # Never log secrets or full SAP payloads.
    print({
        "correlation_id": x_correlation_id,
        "tool": "get_order_status",
        "order_id": order_id,
        "block_count": len(result["blocks"]),
    })

    return result

This is the part that gets skipped in demos and then hurts later. When a user says "the agent told me the wrong thing," you need to reconstruct what it saw, which tool it called, what SAP returned, and which policy version was active.

Without that, you are debugging vibes.

Where the avatar fits

If you are building a Casandra-style avatar on top of this, I would keep the avatar layer dumb.

The avatar can make the interaction feel nicer. It can speak, explain, ask follow-up questions, and show the answer in a more human way. But it should not own the SAP permissions, the OData query, or the policy decisions.

A clean split looks like this:

Avatar / UI:
  - captures the user request
  - shows status and confidence
  - asks for missing order id
  - renders the final answer

Foundry agent:
  - decides whether a tool call is needed
  - turns tool output into an explanation
  - follows response policy

Integration backend:
  - validates input
  - calls SAP
  - trims data
  - logs access
  - enforces authorization

That makes the avatar replaceable. Today it is a web avatar. Tomorrow it might be Teams, Copilot, a mobile app, or a voice interface. The SAP contract stays the same.

The policies I would enforce early

I would not wait for an enterprise governance board to invent a 40-page document. Start with five rules in code:

Only approved tools can access SAP.
Tools must have typed schemas and additionalProperties: false.
The model never receives raw SAP payloads.
Every tool call gets a user id, tenant/context id, and correlation id.
Tool output is logged as metadata, not as full business data.

Those five rules already avoid a lot of trouble.

A small test that catches a big mistake

Here is the kind of test I would add before showing the agent to anyone outside the team:

# test_tools.py
import pytest
from tools import get_order_status


def test_rejects_non_numeric_order_ids():
    with pytest.raises(ValueError):
        get_order_status("4711; $filter=NetValue gt 0")


def test_tool_does_not_return_internal_fields(monkeypatch):
    class FakeSap:
        def get_order_status(self, order_id):
            return type("OrderStatus", (), {
                "order_id": order_id,
                "customer_name": "Contoso Retail GmbH",
                "lifecycle_status": "Blocked",
                "delivery_block": None,
                "credit_block": "Credit exposure exceeded",
                "net_value": 18420.0,
                "currency": "EUR",
                "margin": 0.42,
                "internal_note": "Do not expose this",
            })()

    import tools
    monkeypatch.setattr(tools, "sap", FakeSap())

    result = get_order_status("4711000420")

    assert "margin" not in result
    assert "internal_note" not in result
    assert result["blocks"][0]["type"] == "credit"

A test like this is not glamorous. Good. Glamour is usually where agent projects start lying to themselves.

My take

For SAP integration, Azure AI Foundry becomes interesting when you stop treating it as a chatbot builder and start treating it as an orchestration layer with strict tool contracts.

The model should explain. Your backend should decide what data exists, who can see it, and how it is fetched.

That is less flashy than "natural language over SAP," but it is much closer to something I would trust in a real environment.

Originally published at https://blog.bajonczak.com/a-practical-sap-agent-in-azure-ai-foundry-odata-in-governed-answer-out/.

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.