Skip to content
Merulan

Security

The checks every Merulan call passes, the two things a Workspace administrator sets, what to change when a call is refused, and where the compliance facts live.

Use this page when a call is refused or before you give an API key to a client. It names the checks and the next step. They run on every Surface. Roles and capability bundles, Tags, policy, and field access, and Access reviews and audit own the Governance detail behind them.

Security controls

Every call meets the same three security checks, in the same order. Merulan first checks the credential. It then places the caller in one company and one Workspace. It then asks whether that caller holds the permission the operation names. Nothing runs and nothing changes until all three pass.

A refusal tells you little, and that is deliberate. An expired token, a wrong audience, and a bad signature all return one identical message, so a caller probing the boundary learns nothing about which check fired. More detail would help an attacker.

Security configuration

Two settings decide how far a caller reaches, and both live in the Console. A Workspace administrator sets roles and permissions under Governance → Access Model → Roles. Roles and capability bundles explains the grant boundary. API keys are created and revoked under Settings → Admin → Developers. Access reviews and audit explains their administration. API shows how a key becomes an access token.

A key is a delegation and not a second identity, so it is no security boundary of its own. It acts for one member and narrows that member's permissions rather than adding to them. Widening a key never reaches past the member behind it, and narrowing the member narrows every key they hold.

Revoke a key as soon as its client should stop. Revoking reaches the tokens the key already minted, not only the next exchange, so an outstanding token stops inside its own short life. Keep one key per client, and keep keys out of support notes, examples, and documentation.

Resolve security refusals

A security refusal comes in three kinds, and each one has a different repair.

The first says the credential was not accepted. Exchange the API key again, because the access token expired. API states how long an access token lives. If the exchange itself refuses, the key was revoked, and only a new key repairs it. Sending the raw key to the API host is refused as well, because the exchange happens on the app host.

The second says the caller may not do this. Read the operation page's Permission section, then ask a Workspace administrator for that one permission and no more. A refusal that names the Workspace instead means the caller cannot reach the Workspace the request names. Confirm the Workspace id, then use Workspaces and membership to check whether the member is still in it.

The third says the decision could not be made. Merulan cannot confirm whether the key behind a token is still live, so it refuses rather than admitting the call. Neither a retry nor a new key helps. Wait, then send the call again.

Security assurance

Certification, residency, subprocessors, and response promises can change. The Trust Center holds the live policies, documents, and audit status. The privacy policy names subprocessors and legal terms. Check those sources before a procurement or deployment decision. A copied claim from documentation is not current assurance. Report a vulnerability to security@merulan.com.

Security detail stays with the page that owns each contract: