Connect an AI assistant
to your safety data.

See the highlighted block above the contents list. The rest of this article walks through the three pieces of the machine surface, how the connector authorizes an AI assistant, what stays locked against automation, and what an integration team can actually build.

Most safety platforms keep their data behind the screen. eAviora exposes it deliberately, through three pieces that share one governed path to the same records. They are not three separate products bolted together; they are three doors into one connected operation.

A public REST API v1.The programmatic interface your integration team builds against. It is documented by a spec-from-code OpenAPI 3.1 contract — the specification is generated from the running service, so the documentation never drifts away from the actual behaviour. You point a code generator at the contract and get a typed client in your language of choice. Bearer key authentication, predictable resources, the OpenAPI document as the single source of truth.

An MCP server — connect an AI assistant to your live records. Instead of writing code against the REST API, you let an AI assistant query the same records in plain language. Ask it which open corrective actions are past their verification date, or which occurrences this month touched a particular hazard, and it reaches the live data through the MCP server rather than a stale export. The assistant sees the same records a person would, scoped to what it is allowed to see.

An OAuth 2.1 connector for AI assistants.The consent and identity layer. It authorizes an AI assistant to act as a specific, consenting user, with permission scoped to exactly what you grant. This is what turns “the platform has an API” into “I added a connector, signed in, and chose what it can do” — no key pasted into a chat window, no shared service account.

The connector follows OAuth 2.1, the current best-practice authorization standard, with the hardening details that matter for a system holding safety data. The flow is designed so a credential never sits where it can be copied, replayed, or stretched into long-lived access.

Dynamic client registration (RFC 7591). When you add the eAviora connector in your AI assistant, the assistant registers itself with eAviora automatically using the RFC 7591 standard. You do not hand-build an application registration or trade client secrets by email.

Mandatory PKCE. Proof Key for Code Exchange is required on every authorization, not optional. It binds the authorization request to the same client that later redeems it, so an intercepted code is useless to anyone else.

Single-use authorization codes. The short code handed back after you consent can be redeemed exactly once. A replay of the same code is rejected, which closes the most common interception attack on this kind of flow.

Short-lived access, rotating refresh. An access token lasts about an hour. Behind it sits a refresh token that rotates roughly every thirty days. So even in the worst case, a leaked access token expires quickly, and the longer-lived credential keeps moving rather than sitting static. You can revoke the grant at any time and the assistant loses access.

Scoped consent, granted in-app.When you authorize, you do it inside eAviora, signed in as yourself, and you choose the scopes the connector will hold. The connector then acts as you — the consenting user — for every call it makes. That is the key property: there is no anonymous robot identity. The audit trail names a person.

The point that matters most to a head of safety is not what the connector can do, but what it can never do. Opening a data surface to automation is only safe if the automation runs through exactly the same controls as a person. In eAviora it does — there is no parallel, weaker path for machines.

The same five checks, every call. Whether a request arrives from the REST API, the MCP server or the connector, it runs the identical chain a person runs when they click in the product:

• Scope check— does this credential hold the permission for what it is asking to do?
• Rate limit— automated callers are paced, so a runaway script cannot overwhelm the operation.
• Database-enforced tenant isolation— one operator can never reach another operator's records. The boundary is enforced by the database itself, not just by application code, so a mistake in a query cannot leak across the line.
• Permission check— the same role and access rules that govern the consenting user in the UI govern the machine call.
• Audit log— every read and every proposal is recorded under the consenting user's identity, so a later review can reconstruct exactly what an automation touched.

Governance state is locked against automation.Workflow and governance state can never be set through the API or the connector. Advancing a stage, approving a classification, closing a corrective action, signing an effectiveness gate — none of these can be written by a machine. An AI assistant can read the record and propose the next step, but a named human still makes the call inside the product. The machine surface is read-and-propose only for anything that carries accountability, by design.

Outbound integration is hardened too.When eAviora pushes events out to your systems, those webhooks are HMAC-signed so the receiver can verify the message genuinely came from eAviora and was not tampered with, and the delivery path is hardened against server-side request forgery so the webhook mechanism cannot be turned into a probe of internal networks. Everything — inbound and outbound — is tenant-isolated and audit-logged.

With the surface in place, the practical wins fall into two groups: what an AI assistant does for the safety team in plain language, and what an integration team builds against the REST API.

For the safety team, through the connector. A safety manager who has authorized the connector can ask an AI assistant questions against live data instead of waiting on a report:

• Which open corrective actions are past their verification date, and who owns them?
• Show me the occurrences this quarter linked to a particular hazard, and summarise the common factors.
• Draft a starting list of look-alike events for this new report — for a human to review and confirm.

In every case the assistant reads the live records and proposes. A person reviews the proposal and acts inside eAviora, where the governance gates live. The assistant accelerates the reading and drafting; it never closes the loop on its own.

For the integration team, through the REST API. Because the REST API ships a spec-from-code OpenAPI 3.1 contract, building against it is ordinary engineering work, not reverse engineering:

• Generate a typed client straight from the OpenAPI document and read records into a data warehouse or analytics tool.
• Receive HMAC-signed webhooks when records change, and drive your own downstream notifications or dashboards from them.
• Feed proposals into eAviora from your own systems — remembering that a human still signs off on anything that advances a workflow.

The same governance applies to both groups. Whether the caller is an AI assistant in plain language or a service your team wrote, it sees a tenant-isolated, permission-checked, audit-logged slice of the operation, and it can read and propose but not decide.

The relevant surfaces: Developers and API, Trust and security, Safety analytics. To scope a connection for your operation, contact us.