External capabilities

An External Capability is how you let an agent reach outside FlowLakes, on your terms. It can fetch a web page, send email, query Microsoft Graph for Entra, call a REST endpoint you configure, or read from an MCP server you attach. Each one is a single row you control: which provider, which credential, whether it is enabled, and what it is allowed to do. Capabilities ship disabled, so an agent has no outside reach until you deliberately turn one on. An agent can never make an ad-hoc call; it can only use a capability you configured.

An external SQL database can also become a readable source. You register an existing PostgreSQL data source, run schema introspection, and enable it; agents then see its tables and ask declarative questions (a single table, filters, an aggregate) that the platform turns into safe, parameterized queries on a read-only connection. Agents never write SQL text, and results are capped at 200 rows per call. Enabled sources are also indexed for routing: an agent describes what it needs in a few words and gets the attached sources ranked by relevance, so it finds the right system before it queries anything.

An MCP server works the same way. MCP (Model Context Protocol) is an open standard where a server describes its own tools, so introspection is a natural fit: add the server’s HTTPS address, run Introspect tools, and the platform fetches the server’s tool list with each tool’s typed input schema. You then review the tools and mark the ones you have verified as safe reads. Only the tools you mark read-only become invokable by agents; a server’s own read-only hint is shown as a hint but never trusted on its own. Marked tools appear to agents like any other source operation, with their arguments validated against the introspected schema before any call is made.

When you’d use it

• Let an agent read a web page as part of its research.
• Send email from an agent’s result, as an approved action.
• Query Entra for group and access data through Microsoft Graph.
• Search Microsoft 365 content: find the email or SharePoint/OneDrive document that matches a record (a purchase order number, an invoice, a payment reference) through Microsoft Graph.
• Call an external REST API you have configured, by a named operation.
• Read from an MCP server through the tools you marked read-only, with arguments checked against the server’s own schemas.

What you manage

External capabilities live under AI → Connections (/admin/connections). The list shows one row per connection: what it reaches, whether it is on, which tables may use it, its credential, and what a session can do through it, in a plain sentence. Open a row for its full settings:

• On. Off by default; turning it on is a deliberate choice.
• Posture, and its consequence. What the connection is allowed to do once it is on, read on the page itself rather than left to guesswork.
• Provider and config. For a REST endpoint, an HTTPS base URL and an allow-list of operations.
• Credential. An optional reference to a secret in the credential store; create one in place without leaving the page.
• Try it. One real read through the bound credential, shown to you only, never to a model, so you can check a connection works before anything depends on it.

Some types allow several named instances; the unnamed row is the default. The model this tenant thinks with is no longer a card on this page: it has its own small page, linked from the list, with which model row is in use, whether a key is configured, what it has cost today, this week and this month, and one optional token cap. A setting this list does not show yet, such as an MCP server’s or a SQL source’s own editor, stays reachable from Open the full editor at the bottom of the list.

Adding a connection

Open Admin, AI, Connections and choose Add a connection. The page asks what you want to connect:

• A system with an API. Give it a name and its base URL. Tick I have an API description if you have an OpenAPI or Swagger document. Create and continue saves the connection switched off and opens its page, with the import already open when you ticked the box. On that page you add its operations, pick or create its credential, choose which tables may use it, run Try it, and switch it on.
• An MCP server. Opens the full editor with its Add server card ready.
• A database. Opens the data source builder for a SQL source.
• Asset discovery. Opens Discovery to scan a network, cloud or directory.

Web fetch, email and Microsoft Entra are already in the list for every tenant. You switch them on there; there is nothing to add.

The token cap

The token cap is the one limit a customer sets on how much AI work this tenant does. It counts every model call the tenant makes, including chat and single-shot evaluations, not agent sessions alone. Leave it empty for no limit, which is the default. Work refused by the cap is not lost: it is recorded on the record and starts by itself when the period rolls over. Switching the model row and replacing its key are operator actions, not tenant ones.

For a REST endpoint you can build the operation list from the API’s own OpenAPI or Swagger document. Open the endpoint and choose Import from OpenAPI, then paste the spec, pick a file, or give an HTTPS spec URL the server fetches. You get a preview of every operation with its typed parameters; select the ones to add and save. GET operations are preselected. A non-GET operation only becomes readable to agents when you check Read-only for it, so a POST-bodied search is a conscious choice.

Choosing which directory reads an agent may use

Microsoft Entra reads as one connection with two halves on this list: read the directory and change the directory, opened together on the same page, each with its own on switch, posture, credential and Try it. The Entra Graph Query connection backs everything an agent can look up in your directory: people, groups and their owners, applications and their secrets, directory roles, licences. Open the connection and you get Directory reads, a checklist of every read the platform ships.

A connection you have never edited uses the shipped defaults, and the checklist shows you which those are. Untick a read and agents can no longer use it: an agent that tries is told the read is switched off and who can turn it back on, so a missing answer is never mistaken for an empty directory.

One read is off until you turn it on. Authentication methods exposes how a person signs in, including phone numbers, so enabling it is a deliberate choice rather than a default.

Reads are read-only by definition. Nothing on this checklist can change your directory; changes are proposed as plan steps and approved by a person, which is the subject of the next section.

What an agent can read on an Intune row

Microsoft Intune reads as a second connection on the same Microsoft Graph credential as Entra, so there is nothing new to register in Azure, only a second row to switch on. Create it from the connections list as a named instance called intune, bind the same app registration’s credential, and enable it.

Once enabled, an agent can look up a managed device by id, search for a device by its user’s name, serial number, device name, compliance state or operating system, read its detected apps, compliance and configuration states, its device health script results, the device health script and mobile app catalogues, and per-app install status. Every read is read-only; a wipe or a retire never runs from a chat turn, it rides the same approval-gated plan step every other high-risk Intune action does.

One read is not offered at all. Microsoft Graph exposes a device’s Windows Update compliance state only through its beta surface, and this platform never calls beta Graph endpoints, so that read is refused by name with the compliance read to use instead, rather than silently pointed at beta.

A device’s user name and user principal name are treated as a person, the same as every other directory lookup: masked to the model, shown to the person asking. The device itself (its name, serial number, compliance state, last sync time, operating system) is not a person and is shown in full.

The Intune write door and bulk actions

Changing a device, rather than reading it, goes through the Intune Door, a second shipped connection next to Entra Door: a proposed sync, reboot, remote lock, Defender scan, remediation script or app assignment is read back once a person approves it, and retire and wipe stay disabled until an administrator turns them on by name. A technician can also ask for one approved operation across many devices at once; this runs as a paced, cancellable fan-out job rather than a loop, and a high-risk operation is never offered in bulk. Granting the Graph permissions and deciding what a technician may approve is covered end to end in Connect Microsoft Intune.

What a session can do through a connection

A connection you switch on reaches the record session by itself. Nothing is ticked on an agent, and nobody designs one: the platform decides from the connection’s type what a session may do through it, and the row’s sentence ends with that answer.

• The session reads it now. The connection has a read the session may call on its own, within the connection’s own limits. Microsoft Entra (the directory reads you enabled) and Web pages (the hosts you allowed) are of this kind. The session is told, before it starts, which reads it holds and what the limits are.
• The session may propose changes through it; a person approves. A REST connection is of this kind: the session proposes a step, the step is graded, and the sign-off ladder decides it. A change through a connection is never a direct call.
• No session can use it yet. Email and MCP servers are connected but no session reads or writes through them yet. The session is told the connection exists and why it is out of reach, so it never guesses at it.

The answer depends on the connection being on and on the tables it may serve. A connection that is off, or scoped to other tables, gives the session nothing, and the session says so by name.

How far a connection may go

A connection that can CHANGE something outside FlowLakes carries one more setting: how far it may go. There are three choices and no other dials.

• Observe. Agents read and propose, but no change to this system can be planned at all. A plan that tries is refused before it exists, and the agent is told why so it can record the change a person needs to make instead. This is how you try an agent on real requests with nothing at stake.
• Assist. The default, and what every connection did before this setting existed. Agents propose changes, and a person approves every one of them before anything runs.
• Trusted. As Assist, and low risk changes can stop needing an approver once the agent has a track record of the same shape being approved by people. It never skips the approval ladder for anything above low risk, and an approval policy still has to turn auto approval on.

Moving the dial is recorded with who moved it and what it was before.

Risk levels, and the groups nobody touches

Each write operation on a connection carries a risk level you set: low, medium or high. It decides which approval a proposed change goes to, so routine grants stay cheap and dangerous ones stay slow without anybody labelling each individual request. An operation nobody has set a level for is treated as high, and the page says so rather than staying quiet about it.

Two things then raise or refuse a change automatically, from facts rather than from settings:

• Group size. Set Escalate above to a member count and a change to a group larger than that is graded one level higher. Leave it blank and the rule is off.
• Groups that are never touched. A group that can be assigned Entra directory roles, and a group whose membership Entra computes from a rule, are refused outright. That set is derived from Entra’s own facts, so a group created tomorrow is protected the moment it syncs, and no screen can take a group out of it. Groups to leave alone lets you ADD your own, by name or by id. An id is the stronger entry: it holds even when the directory cannot be reached to look the group up.

Each posture also caps how much can change: Assist allows at most 5 changes in one plan and 50 in any 24 hours, Trusted allows 10 and 200. The 24 hour figure counts changes that actually ran, on a rolling window rather than a calendar day, and a plan that would go over it is refused with the numbers spelled out. The caps are checked again just before a plan runs, so a plan approved yesterday cannot spend a budget that has since been used up. It stays approved and can be run once the budget frees up.

Underneath every one of these settings the page prints what the platform will actually allow, in plain sentences. The same sentences appear in the Agent Designer and above every plan waiting for approval, so the person setting a fence and the person approving a change read the identical words.

Who signs off, per risk level

Every connection that can change something shows a Who signs off block: for each risk level, which approval policy would decide a change through this connection and who that resolves to today. The block is read from your approval policies each time the page loads; nothing about approvers is stored on the connection, so it cannot disagree with what happens when a plan is proposed.

• Out of the box, every tenant has a platform ladder: three policies named Governed external changes, one per risk level, naming the tenant’s administrators. Edit who approves on the Approval Policies page; the risk level of a change is decided by the platform per plan and is not a setting on the policy.
• A policy that names a connection (a condition on capability_name) takes precedence over the ladder for that connection, so one system can have stricter or different approvers than the rest.
• A dynamic approver such as the requester’s manager is shown as its rule, because only a real request can name the person.
• A level marked No approver today means a change of that risk through this connection would be refused when proposed. Add an approver to the policy, or switch the platform rung back on, before anyone expects that operation to work.

Which tables may reach a connection

A connection reaches nobody until you say which tables may use it. Open the connection and you get Which tables may use it, with three choices: no table, every table with sessions, or only the tables you tick. A new connection starts at no table, so an HR process cannot find a Finance system through a connection somebody merely switched on. Every table is shown in warning tone, because it is the open setting; choose it on purpose, and narrow it when you can.

The same setting is on each application’s Setup, under the Assistant stage: the connections its tables’ sessions may use, one switch per connection. A switch there changes the connection itself, so it needs the connection permission; without it the stage says where the setting lives. A connection open to every table cannot be narrowed from one application’s page, since that page cannot know which other tables should keep it. Narrow it on the connection.

Connections that existed before this setting arrived were set to every table, so nothing they served stopped working. The Connections page shows that beside each one, which is your cue to narrow it. A shipped connection, such as the Entra write door, arrives open to every table for the same reason and is yours to narrow after install. A package update never changes the scope you set.

A session on a table the connection does not list sees the connection as out of reach, and the record’s audit account, behind the rail’s Audit link, says so: enabled, but reaches no table yet, with the page where that is set.

House rules on a connection

Every connection carries a House rules box: the standing instructions a session is given whenever it reaches that connection. Write there what the model should know about the system itself: what to read before proposing, which requests are out of the connection’s reach and who owns them, what to ask a person, how to write for the approver. A rule about a system belongs on the system, so every session that reaches it reads the same rules, and no agent has to be built to carry them.

House rules are guidance. What the platform enforces is the operation list on the connection (an operation not listed cannot be proposed), each operation’s risk level, how far the connection may go, and who signs off. Editing the rules needs the AI skills permission, because the text changes what every future session is told; a reader without it sees that rules exist and nothing of what they say.

Shipped connections

FlowLakes ships some connections ready-made as blueprints, so a system can be reached without anyone designing the connection or an agent for it. Installing one creates the connection disabled, at the observe level, with no credential, together with its house rules and, where the system needs one, an approval policy for its high-risk changes. You bind a credential and enable the connection on this page; the blueprint never ships a secret and never opens a door.

The first shipped connection is Entra Door: the Microsoft Graph write connection for Entra ID, its twelve governed operations (group membership and ownership, app roles, licences, manager, user updates, sign-in revocation), the house rules for Entra (lockouts and risk flags are read and handed to a person, never revoked; guest invitations and time-bound access are asked about, never guessed; directory roles, Privileged Identity Management and Conditional Access are named as out of reach), and a high-risk override decided by the Entra Access Admin role. The read side, the directory queries, is the platform’s own default connection and is configured separately.

Workflows use the same registered endpoints

A workflow that calls an outside system uses the endpoints you register here, not an address typed into the workflow step. In the workflow designer, the REST API Call step asks for two things: which registered system, and which of its operations. The address, the HTTP method and the credential all come from the endpoint you configured, so a workflow can only reach systems you reviewed, and every call it makes is recorded against that endpoint.

Steps built before this change, which held their own web address and token, stop and say so. Register the system they used, then set the step’s system and operation. Any credential that was typed into such a step has been removed from the database and should be rotated and stored in the credential store.

Good to know

• Everything ships disabled. Least privilege is the default; nothing reaches out until you enable it.
• There is one outbound door, for agents and workflows alike. Neither can call an address you have not registered, so one allow-list and one record of activity cover both.
• A missing or disabled capability fails loudly, not silently, so an agent cannot quietly bypass it.
• A Graph permission denial tells you what to grant. When Microsoft Graph refuses a call because the app registration lacks a permission, the platform names the connection and, when Graph named it, the exact scope to add, and files a setup request on this list. Add the scope in the Entra app registration and grant admin consent there. The platform never calls Graph to grant a permission itself and never retries the read on its own; approving the request only resumes the agent once you have made the change.
• Read capabilities run on their own; write capabilities stay approval-gated. Fetching a page or querying Graph is read-only; sending email or calling a REST endpoint waits for approval.
• The Entra Graph tool is read-only and uses named operations, never a raw URL. Entra writes are carried out by an approval-gated workflow, not the agent.
• A refusal is not a strict approval. A change the platform refuses is never routed to a tougher approver instead; the plan is not created at all. No approver can wave one through and no setting switches one off.
• Microsoft 365 content search is a separate permission from directory reads. The content tool (mailbox messages, SharePoint and OneDrive document search) rides the same Graph capability row and credential, but it is gated by its own platform capability, so granting an agent directory lookups never also grants it mail or document content. Document search needs a search_region value on the Graph capability config (for example NAM or EMEA), and the Entra app registration needs Mail.Read and Files.Read.All or Sites.Read.All consented. Scope mailbox access with an Entra application access policy rather than leaving it tenant-wide. Search results return summaries and links, and a truncated result says so; an agent is instructed to never treat a truncated search as proof a document does not exist.
• Credentials are never stored in the capability. They live in the credential store and are applied only at call time.
• Switching on a connection that needs a credential is refused with no credential bound. Microsoft Entra Graph Query cannot be turned on without a credential that resolves to a real credential of your own tenant; the save is refused on the spot, naming why, instead of the connection going live and failing silently the first time an agent tries to use it.
• Database sources are read-only and permission-gated. Reading a registered database needs the platform.external.sql.read capability (REST sources use platform.external.rest.call), the session is forced read-only, and every table or column an agent names must exist in the introspected schema. A database behind an on-premises agent cannot be registered yet.
• MCP servers are read-only by explicit marking. Reading an MCP server needs the platform.external.mcp.call capability, and an agent can only invoke tools you marked read-only after introspection. Tool descriptions and schemas come from the server, so the platform treats them as untrusted: descriptions are length-capped, secret-shaped parameter names are stripped, and a tool whose schema cannot be represented is called without argument checking and says so honestly. Connections use HTTPS with a credential from the credential store; servers that require an OAuth sign-in flow are not supported yet and refuse with a clear error.
• An imported spec never brings its own auth. Security schemes in the document are ignored, header parameters are dropped, and secret-shaped parameter names are stripped from the preview; bind a credential on the endpoint instead. A spec whose servers disagree with the endpoint’s base URL is refused outright.
• Every source can carry a call budget. Set optional limits on any source: calls per run (how often one investigation may query it) and calls per hour (a tenant-wide cap). When a budget is reached the agent gets a clear refusal telling it when the window resets, so a runaway loop cannot hammer a metered third-party API. Unset means unlimited.
• Successful extractions become recipes. When an investigation that queried a source finishes with a finding, the platform records one extraction recipe per source and operation used: the question asked, the parameter shapes that worked, and what came back. Agents recall these before probing a source again, so extraction improves with use. Recipes store parameter types, never the values; disabling a source keeps its recipes, deleting it removes them.

How it connects

An External Capability is the configuration and the outbound call. Whether an agent may use it is decided by its tool grants and the Safety model. The secret it uses lives in Credentials and secrets.

• Enable and configure a capability in the admin guides.
• Exact shapes: capability table fl_external_capabilities (types web fetch, email, Graph query, REST endpoint, MCP server); every term in the glossary.