Skip to main content

🧩 Beak Hub – Release Notes

Changelog for the MCP server, agent and agent-suite catalog and the MCP gateway.

Note: This changelog starts at version 6.0.0. Earlier Beak Hub releases are not recorded here.

Version 6.0.1​

The Microsoft MCP servers act as you using your existing Microsoft sign-in​

Azure, Microsoft Entra, Microsoft Fabric and Azure DevOps were described in 6.0.0 as acting as you by exchanging your Beak identity for a Microsoft one. Microsoft does not accept a Beak identity that way and never did, so that path could not work. These four now use the token Microsoft already issued for you when you signed in to Beak through Microsoft. See MCP Servers.

  • What you can do that you could not before. Use Microsoft Entra tools as yourself, with your own directory permissions — so a person who cannot reset a colleague's password in the Microsoft admin center cannot do it through an agent either. Previously every call used one shared application identity. The Microsoft Graph parts of Microsoft Fabric work the same way.
  • Azure, Azure DevOps and the Fabric and Power BI parts of Microsoft Fabric cannot act as you yet, and now say so. Microsoft issues a token for one service at a time, and the token from your sign-in is issued for Microsoft Graph. Rather than use a shared identity and appear to work, these refuse and name what is missing. Widening this to those services is planned work.
  • No Microsoft application registration or secret is needed for this, and the affected servers no longer ask for one on a personal connection.
  • Two things an administrator turns on first, in Beak IAM, per Microsoft sign-in: keeping the provider's tokens, and allowing them to be read back. That stores a Microsoft credential for each person who signs in, so it is a deliberate decision — see Company SSO. It captures only sign-ins that happen after it is switched on, so people already signed in must sign in again, and the read-back permission reaches only people who link to Microsoft after it is on. Each server is then given two settings, once per environment: which Microsoft sign-in to read from, and which Beak IAM addresses it may read from at all — the second is a safety check, so a server only ever fetches a token from an address an administrator listed.
  • Nothing changes unless per-user identity is already enabled on one of these four servers. The shared-identity behaviour on team and agent connections is untouched.
  • Every refusal names its cause — token storage not switched on, the person not linked to Microsoft, the read-back permission missing, the stored token expired, or the service needing a token that has not been issued yet. Each has a different fix, so they are reported separately rather than as one authentication failure.

Version 6.0.0​

A tenant is registered with the Hub when it is created​

A tenant used to be added to the Hub by hand on the admin page, and its system roles appeared only when somebody happened to sign in. Both now happen when the tenant is created.

  • The tenant is registered under its platform tenant id, so the Hub's view of a tenant is the same tenant every other product means.
  • Its system roles exist from the start, rather than being created lazily at first login.
  • The Hub reports whether the tenant has an active key, which is what makes it usable. The key itself is still created from the Runtime setup wizard.

On by default for newly created tenants; existing tenants are untouched. See What Each Product Sets Up.

MCP servers can be connected with OAuth, using your own identity​

An MCP server in the catalog can now declare that it is authenticated with OAuth rather than with a static key typed into a dialog. Connecting such a server sends you to an identity provider to sign in, and Beak Hub holds a token bound to that specific server instead of a shared secret. See MCP Servers.

  • What you can do that you could not before. Use an MCP server that requires standard OAuth, and connect it as yourself rather than through one credential shared by everyone in the tenant. The server sees who is calling and applies your own access, so two people connecting the same server hold two separate authorizations and revoking one does not affect the other.
  • Your organization's identity provider works here. The beakiam method routes authorization through Beak IAM, which federates to Microsoft Entra ID, Okta, Google, any OpenID Connect provider, or SAML. Administrators decide who may reach which MCP server in one place.
  • Off by default, and nothing changes for existing connections. The new methods are opt-in per catalog entry. Every connection you have today keeps working exactly as it did, with its credentials still injected as before and its bearer token unchanged. No connection needs to be recreated on upgrade.
  • Authorizations renew themselves. An expiring access token is refreshed without anyone doing anything. A connection only asks for attention when the identity provider has actually refused it, and the Connections panel says which state each connection is in.
  • Removing an authorization keeps the connection. The bearer token stays valid, so clients already configured with it keep working once you re-authorize. Only disconnecting the instance invalidates the token.
  • New permissions are added, never swapped. If a server later refuses a call because it needs a permission you have not granted, re-authorizing requests that permission in addition to the ones you already granted, so other tools do not silently lose access.

Reach an MCP server with the sign-in you already have​

A user who has authenticated at their own organization's identity provider can now reach an MCP server without signing in again. Their provider's token is exchanged, through Beak IAM, for a token bound to that one server and carrying their own identity.

  • Which providers can reach which servers is an explicit, audited decision. Registering a server and granting a user access is not sufficient; an administrator also permits each identity provider for each server, and that grant can be revoked.
  • A one-time interactive sign-in is required per user. The exchange works once a user's Beak account is linked to the provider, which happens the first time they sign in through it or when the directory sync establishes the link. A user created by bulk import who has never signed in is refused, with a message that says exactly that rather than a generic authorization error.
  • Nothing changes for existing connections, and this is off until an administrator permits a provider for a server.

Known limitation. Beak Hub sends the standard resource indicator on every authorization and token request, as the specification requires of a client. The identity platform version currently deployed does not act on it, so a token's audience is bound by its client registration instead. The effect is the same — a token issued for one MCP server is rejected by another — and this note will be removed when the identity platform is upgraded.

The pre-built MCP servers can act as the person calling them​

A pre-built MCP server used to reach the system behind it through one shared service account, whoever triggered the call. Fifteen of them can now make that call as the person instead, so the system applies that person's own permissions.

  • Six reach another Beak product — Beak ELM, Beak FinOps, Beak M365, Beak ITSM, Beak Task Manager and Beak Observability. The product authenticates the call as the person who triggered it and applies their own role, permissions and company scoping: the same access they would have signing in to that product directly. Access is read live, so a permission granted or removed in the product takes effect on the next call with nothing to reconnect.
  • Five reach the older platform — Beak ITAM, Beak Vulnerability, Beak Endpoint Automation, Beak Patch Manager and Beak Desk Task. That platform does not read a Beak identity directly, so the server hands it over once and receives a session for that person, then makes every call in it. The result is the same — the product applies their own role and company access — but it needs two things from an administrator first, in each environment: one matching key set on both the MCP server and the older platform, so it knows the caller is a Beak service rather than a browser (the key grants no access on its own — the person's identity is still what is verified), and the person must already have an account there (this flow does not create one). Both refusals say exactly what is wrong instead of falling back to the shared account.
  • Four reach Microsoft — Azure, Microsoft Entra, Microsoft Fabric and Azure DevOps. This shipped describing an exchange of the person's Beak identity for a Microsoft one, which Microsoft does not accept; see 6.0.1 below for what these four actually do and which of them can act as the caller today.
  • Personal connections only. A connection shared with a team, or owned by an agent for unattended work, keeps using the shared service identity — an unattended run must not act as an absent person.
  • Off by default, enabled per server by an administrator, and worth planning. An agent running today on a shared service account may have broader access than the people who use it. Moving it to per-user identity is the correct end state, but it can narrow what that agent reaches, and some calls will start being refused — correctly — because the person behind them does not hold that access. When that happens the fix is a grant in the product, as for anyone using it directly; the connection does not need recreating. Nothing changes on upgrade until it is switched on.
  • The two servers that cannot do this say so. Beak NOC and Smart Work Analytics talk to systems that do not accept a Beak identity on any route, and their catalog entry states it, so an administrator granting access knows they are granting whatever the shared credential can reach.

See MCP Servers.

A server can be switched to per-person authorization one environment at a time​

Turning a pre-built MCP server over to per-person authorization used to mean editing the server's own catalog entry, which every environment shares. An administrator can now do it per environment instead, so a change can be proven in development before it reaches anyone else.

  • What an administrator can now do that they could not before. Switch one server, in one environment, from a shared static key to per-person authorization — and switch it back just as quickly if an agent turns out to depend on the broader access the shared account had.
  • Why it could not simply go in the catalog entry. Each environment has its own identity provider, and a server's catalog entry is pushed to every environment each time the Hub starts. An entry naming one environment's provider would point all of them at it. The entry now keeps a static-credential default and an environment is switched over explicitly, so development, test and production are independent.
  • Off everywhere by default, and existing connections are untouched. No environment changes behaviour on upgrade. A server only starts asking people to authorize once an administrator has switched that environment over.
  • A mistyped setting stops the service rather than being ignored. If the value does not name a real authentication method, the Hub refuses to start and says which setting is wrong. Leaving an environment quietly on its old method would look like the change had worked while every call still used the shared account.
  • What it requires. The server registered in Beak IAM, the access role granted to the people who will use it, and — for the authorization step itself — an existing Beak sign-in in the browser. See MCP Servers.

Agent-owned MCP connections are authorized before every tool call​

An MCP connection owned by an agent identity now has each tools/call checked against that agent's scopes in Beak AI Security before Beak Hub forwards it to the server. Previously the connection was the only gate: once an agent held a connection token, every tool on that server was callable regardless of the scopes the agent had been granted. See Governing an Agent from Any Platform.

  • A denial comes back as a JSON-RPC error. The MCP client receives error code -32001 with the reason and a machine-readable code such as scope_insufficient or tool_denied. One denial in a batch refuses the whole batch.
  • The check fails closed. If Beak AI Security is unreachable, answers an error, or is not configured on this Hub, the call is refused with a distinct code (authz_unavailable, authz_unconfigured) rather than forwarded.
  • Only agent-owned connections are affected. Connections scoped to a person or shared with a team are authorized as before. Listing tools and initializing a session are never blocked.
  • Creating an agent connection records the hub.tools grant on the agent's governance profile in Beak AI Security, so an agent whose tools go through Hub is reported as governed at the tool boundary without an operator recording it.

Note: Tool authorization is on for every agent-owned connection once SECURITY_SERVICE_URL is set on Beak Hub, and refuses tool calls on such connections while it is unset. Beak AI Security answers the authorization call only when the Hub signs it, so AGENT_GOV_ENVIRONMENT and AGENT_GOV_WORKLOAD_PRIVATE_KEY_PEM must also be set and the Hub public key provisioned as a trust anchor in Beak AI Security — the same key that records grants. Until they are, every call is refused unless Security's TOOL_AUTHZ_ALLOW_UNAUTHENTICATED_IN_CLUSTER rollout switch is on.