News

What’s new at Boundlane.

Product releases, technical perspectives and company updates.

  1. Product

    Boundlane Gateway: your people’s own assistants on your business systems, starting with Oracle Fusion

    Your people can use the assistant they already have on your business systems, governed by one engine. Oracle Fusion Cloud ERP is the first certified connector, and Gateway is open to design partners.

    Read the update

    Boundlane Gateway is a second door. Studio builds automations and Control runs them. Gateway governs the assistants your people bring: any assistant that supports remote MCP servers with OAuth sign-in, including an agent your team built. It uses the same Boundlane account, sign-on, approvals inbox, audit chain and bill as Studio and Control.

    One engine governs every system: each person’s own credential for the system, role-based policy, approvals bound to the exact change, a hash-chained audit trail and entitlement reports. A connector adapts it to each system. Boundlane is the control plane, and each connector cell is a separate deployment of the engine for one customer, in AWS in the EU (Stockholm) by default.

    Oracle Fusion Cloud ERP is the first certified connector. Each person connects their own Oracle account once, and Oracle enforces that person’s roles and data security on every call. Your policy narrows that further, to explicit fields, business units, legal entities and ledgers. Oracle’s record version is checked before a change applies, and the record is read back afterwards.

    On 6 November 2026, 39 Oracle operations pass Boundlane’s activation gate: 36 reads and 3 changes, each with a reviewed usage contract and probe evidence from a live Oracle Fusion test environment.

    The MCP connector brings the same engine to any business system that publishes a remote MCP server: per-person OAuth to the system, per-tool grants with argument limits, approvals for changes and the same audit chain. As of 6 November 2026 it is proven end to end against a reference system in Boundlane’s test harness, and it is not yet certified with a specific vendor’s server. More certified connectors follow design partner demand.

    How Boundlane Gateway worksConnect your assistantHow Gateway is governed
  2. Product

    Above a limit, a person approves

    Administrators set approval limits per currency. A payment over the limit waits for someone who may decide it, and so does every write that depends on it.

    Read the update

    A workspace sets an amount for each currency it pays in, and optionally the business role that decides above it. An automation can carry lower limits of its own, and the lower limit applies.

    Boundlane never guesses where the amount is. Each action that moves money states which field holds the amount and which holds the currency, and the checks before release refuse a payment action that does not say so while any limit is in force. An amount that cannot be read counts as over the limit, and so does a currency with no limit of its own.

    An over-limit payment does not run. It is held, and every write after it is held with it, so marking an invoice as paid cannot run ahead of the payment it assumes. Reads continue. The held calls become one proposal for the person who may decide, stating each amount and the limit it exceeds, and approving it performs them in order.

    Before saving a change, preview its effect: Boundlane replays recent runs against the proposed limits and shows which payments would newly wait, the largest amount in each currency, and any money-moving action no limit reaches.

    Approval limits and hard limits
  3. Product

    Work in Boundlane from your AI assistant, with your policy deciding

    Boundlane is a remote MCP server. Connect any assistant that supports remote MCP servers with OAuth sign-in, sign in as yourself, and choose what it may do.

    Read the update

    People ask an assistant before they open another console. Connected to Boundlane, an assistant can read the workspace’s automations, runs, pending approvals and open exceptions, and start or continue a build in Studio from a description of the process.

    It acts as the person who connected it, and never as more. That person chooses read, operate or build access when connecting, and every request is checked again against their current membership. An assistant cannot decide an approval: it hands over the link, and the person decides in Boundlane. Releasing a version, widening a rollout and handling credentials stay in Boundlane too.

    An automation can also expose chosen actions to outside agents. Each call meets the same policy as the automation’s own runs: the rollout stage, approvals, approval limits and the forbidden list. An agent can propose a call instead of making it, and once a person approves it, exactly that call runs. Every call is recorded as a run.

    Administrators see the connected assistants, who connected each one and with what access, and can disconnect any of them.

    Connect an assistantHow policy decides what executes
  4. Product

    A receipt for every run, and runs that propose before they act

    Every run has a receipt stating what it did and on whose authority. A run can also start as a proposal: it reads real data, records its writes, and performs them only once a person approves.

    Read the update

    A run receipt lists each action the run took and what became of it, with the authority for it in words: the rollout stage that permits it, the person who approved it, or the rule that refused it. It lists the approval decisions, the records and documents the run read, and the audit entries that record it. It is assembled from the record when you ask for it, can be printed or downloaded, and carries a digest of its contents.

    When you start a run of an automation without an approval step of its own, you can choose Propose first. The run rehearses the case against real data, records every write without performing it, and files the writes as one proposal. Approving it performs exactly those writes, in order, at the automation’s rollout stage, with the forbidden list and approvals still applied to each. An assistant can start a run this way too.

    Evidence for every run
  5. Product

    MCP, governed like anything else that can write

    Boundlane connects to remote MCP servers. Every tool such a server exposes is classified as a high-risk write until a person says otherwise, because the protocol carries nothing the policy layer can decide on.

    Read the update

    An MCP server already lists its tools with their inputs, which is most of what Boundlane Studio otherwise works out by hand from an API reference. What it does not carry is what governance decides on. MCP gives a tool a name, a description and an input schema. It says nothing about whether the tool changes anything, how much risk it carries or how to undo it — the three things Boundlane needs to know before a call leaves the platform.

    What MCP offers instead is optional hints, such as read-only or destructive, and the MCP specification itself says a client must not rely on those for security decisions, because the server supplies them. So Boundlane classifies, and the server does not. Every MCP tool starts as a high-risk write: in rehearsal it is recorded and changes nothing, and it does not run at any rollout stage that withholds high-risk writes. The server’s own hints are recorded next to the classification, as an unverified claim a reviewer reads rather than as an input to the decision. A person in your workspace may narrow the classification for a specific tool, and the checks before release refuse an MCP tool that nobody classified. Silence never means read.

    Change is the other half. An MCP server may change its tool list whenever it likes and merely send a notification, and a connection must not change underneath an automation that was released on evidence. So Boundlane records a fingerprint of the tool names and their inputs when an automation is released. A call is refused before it is made if the server no longer matches, and a new release is refused if the live server has moved. Descriptions sit outside the fingerprint on purpose: they are the server operator’s prose and never reach a decision, and including them would make a copy edit look like an attack.

    One boundary, by design. Boundlane connects to remote MCP servers over HTTP and does not run local ones: a local server is a program of a customer’s choosing running on shared infrastructure, which is a different product. Calls to an MCP server reach only approved destinations, like every other connection.

    Why every MCP tool starts as a high-risk writeHow policy decides what executes
  6. Company

    The company is Boundlane

    One name for the company and the platform. Boundlane AG is the contracting entity for the hosted service.

    Read the update

    Boundlane AG is the contracting entity for the hosted service, and Boundlane is the platform it provides.

    Three surfaces over one versioned automation. Boundlane Studio builds an automation and proves it. Boundlane Control runs it under policy. Boundlane Exchange is where a published one is found and installed. The version that passes the checks before release is the version that runs: Boundlane fingerprints it at release and refuses to run it if its code has changed.

    One set of controls spans all three. A single policy layer decides every action an automation takes, and one tamper-evident audit trail records it.

    What Studio and Control do
  7. Product

    Connect the systems we do not ship a connector for

    Boundlane Studio explores an unfamiliar API, describes it, tests the description against the real system and puts it to use — as a reviewable description rather than generated code, so every control on a built-in connector applies to it too.

    Read the update

    Boundlane includes thirteen connectors. A company’s process always also runs through something else: a warehouse system written in 2009, an internal approvals service, a regional bank portal, a vertical SaaS with four hundred customers. An automation that stops at the edge of the systems with a ready-made connector hands the work back to a person, and that handoff is the thing Boundlane exists to remove.

    The obvious answer is to have the model write integration code, and it is the wrong one. Code nobody reviewed would run against a live system, and every promise about connections — calls reach only approved destinations, credentials stay in the vault, every change states its risk and how to undo it — would depend on what the model happened to write. A description is reviewable data instead. Boundlane checks it the same way it checks its own connectors, and every call it makes meets the same policy decisions, approvals and checks before release.

    Four things follow, and they are the whole reason to do it this way. It reaches only the destinations your administrators approved for that connection. It never holds a credential: it refers to one kept in the vault. It cannot describe a change without stating that change’s risk and how to undo it, and it cannot describe an action your workspace forbids. And it cannot change under an automation already in use: the automation records the version of the description it was released with, and the checks before release refuse one that does not match.

    Two decisions in how it explores are worth arguing with rather than skimming. Exploration sends read requests only — there is no phrasing of “just testing” that undoes an exploratory call which created a record in a customer’s production system. And what the API returns is redacted before the model sees it, because the first thing an unknown API returns is usually a page of real customer records, and the agent needs the field names and the value shapes, not the third customer’s email address.

  8. Product

    Connectors for the systems a process runs through, not only the ones it settles in

    Ten vendor systems plus generic REST, GraphQL and SQL, and a catalogue of 58 business actions those systems expose.

    Read the update

    An automation that reads an ERP and writes a ledger still stops short of the work. A purchase request is approved in ServiceNow, an exception becomes a Jira issue, the customer hears about it through Zendesk, and the commercial terms sit in a CRM that is not always Salesforce. Boundlane connects Salesforce, Oracle Fusion, NetSuite, QuickBooks, SAP, Snowflake, ServiceNow, Jira, Zendesk and HubSpot, with generic REST, GraphQL and SQL for whatever else a process touches.

    The more useful half is the action catalogue. A connector that can only read, create and update records can see a schema and change a field, and it cannot reach a single operation an enterprise process is actually about: submit an invoice for approval, post a journal, release a hold, assign a ticket, close a case. Without those, an automation works around them by setting a status field and hoping the far system treats that as the action — which skips the vendor’s approval routing, its ledger entry, its notification and its own audit record, and looks like it worked.

    So the actions are described. 58 of them, each with the request that performs it and the risk level the policy layer decides on. Every one changes something — reading is what a schema is for. Each entry maps to a request Boundlane can actually send, which keeps the catalogue from turning into a wish list.

    Most of them cannot be automatically reversed, and the honest form of that is an empty field rather than a reversal that does not work. One is listed only where the vendor has an absolute inverse needing nothing the original call did not already carry: assign and unassign, hold and release, solve and reopen. Setting a priority has none, because undoing it needs the value that was there before — a reversal that set the same value again and reported success would be worse than admitting there is none. When an automation requires every change it makes to be reversible, the checks before release refuse one that uses an irreversible action.

    Every entry names its source: the vendor’s published API documentation.

  9. Product

    Backtesting a candidate version against every run that already happened

    Replay a new version through the whole run history and read the cases where it now decides differently. It emits no score and no verdict, deliberately.

    Read the update

    Rehearsal answers “what would this do” honestly and at the speed of the business: run the automation beside the real process, recording what it would do and changing nothing, wait a fortnight, read the runs. That is the right mechanism and it is why nothing here reaches production on day one. But it only answers forward. The cases that would settle the argument fastest are already sitting in the run history, each with its exact input and every system response attached.

    A backtest is that history replayed. Every past run becomes a scenario, the candidate version runs against it using the responses recorded at the time, and the report lists in full every case where the candidate reached a different outcome than the run actually did. Nothing leaves the platform while it runs: the system responses come from the recording rather than from the system, so nothing is changed.

    It emits no score. “Ninety-four per cent agreement” invites promoting on a number, and the six per cent is the entire content — a version that agrees with history everywhere is either correct or has learned to reproduce the same mistake, and only the disagreements tell those apart. So the report leads with the disagreements, lists every case it could not replay together with the reason it could not, and names the versions the history came from, because more than one means the baseline being compared against is not a single behaviour.

    And it does not replace rehearsal. A replay cannot discover that the upstream system now answers differently, and it cannot observe a case that has never happened. Every backtest report states that limit itself, so nobody reads the results without it.