Controls, shown

How the boundaries hold.

  1. Tenants are separate.

    Each organisation’s data sits inside its own boundary. Requests are evaluated within one organisation’s policies, never across them.

  2. Every request has an identity.

    A person signs in; the AI acting for them is a known agent with its own permissions and a delegation.

  3. Credentials stay inside Kroy.

    Connections to your systems are held by Kroy and used only to carry out authorised requests.

  4. Source systems keep their authority.

    Kroy cannot grant more than Xero or SharePoint allows. It can only narrow access further.

  5. Revocation is immediate.

    Disconnect an agent and its route closes. Future requests are refused.

  6. Everything is recorded.

    Allowed or refused, each decision is written to the audit trail with the rule that made it.

Tenant ATenant B
Kroy
Kroy
Priya
Claude
Claude
CREDENTIALS
Xero source authority
Tenant B user
SharePoint
AUDIT TRAIL
Tenant ATenant B
Kroy
Kroy
Priya
Claude
Claude
CREDENTIALS
Xero source authority
Tenant B user
SharePoint
AUDIT TRAIL
Two separated tenants, each with identity, credentials, source authority, revocation and audit. Tenants are separate.. Every request has an identity.. Credentials stay inside Kroy.. Source systems keep their authority.. Revocation is immediate.. Everything is recorded..

Overview

Kroy is built on one idea: AI never needs the keys to your business. Your systems connect to Kroy. Your AI connects to Kroy. Every request between them is checked, executed by Kroy, and recorded.

CredentialsHeld by Kroy, never given to AI
Every requestPerson, agent, delegation, policy, approval
AuditAllowed and refused requests are recorded
RevocationOne place, effective for future requests

How are credentials stored?

When you connect a system such as Xero or Microsoft 365, the connection — OAuth tokens or service credentials — is held by Kroy. It is used only by Kroy’s Connectors to carry out requests that have already been authorised.

Credentials are never returned through the API, MCP or the panel.

What does an AI provider receive?

An AI tool connected to Kroy receives the result of each authorised request: the records, documents or confirmations that request was permitted to return. It does not receive credentials for your systems, and it does not receive data outside the permission boundary of the request.

Whatever an AI tool receives is then processed under that AI provider’s own terms. Choosing which AI tools are approved for which information is an organisational decision — PolicyHQ helps you make it, and Kroy enforces it.

How are permissions calculated?

Every request is decided against the same questions, in the same order:

Incoming requestAgent requests an action on a resource
  1. Identity Which person or service is asking?
  2. Agent Which AI client is acting?
  3. Delegation What has the person authorised it to do?
  4. Resource Which entity, record or system?
  5. Policy What do the organisation’s rules allow?
  6. Approval Must a person decide first? !
Only then does Kroy execute — and the decision is recorded either way.

An agent can never hold more access than the person it acts for. A Skill narrows that access further to what one task needs.

Can an AI bypass Kroy?

Not for systems connected only through Kroy. If the AI holds no credentials for a system, it has no route to that system except through Kroy’s checks. Instructions given to an AI — including attempts to persuade it to ignore its rules — do not change what Kroy permits, because the decision is made by Kroy, not by the AI.

Kroy cannot control access that exists outside it. If a person also connects an AI directly to a system, that connection is outside Kroy’s boundary. We recommend retiring direct AI connections once a system is connected through Kroy.

How do guest access and external AI work?

A guest — a client, auditor, adviser or contractor — is a named principal with their own identity, a defined role, an optional expiry date and a full audit trail. They see a projection: only the portion of a record you chose to share.

If a guest connects their own AI, that AI acts under the guest’s delegation and is bounded by the same projection. Asking it for anything outside the projection — your internal notes, another client — is refused by Kroy.

How are actions audited?

Kroy records each request that passes through it: the person, the agent, the resource, the action, the policy that decided it, any approval, and the outcome. Refused requests are recorded as well as permitted ones.

How is access revoked?

Remove a person, disconnect an AI client, end a guest’s access or disconnect a system, and Kroy stops authorising the affected requests.

What happens after information has been disclosed?

Revocation stops future access. It cannot recall information that a person or their AI has already received. This is why Kroy is designed around projections: share only what an audience needs, so there is less to worry about later.

How are tenants isolated?

Each organisation’s data is separated from every other organisation’s, and every request is evaluated within a single organisation’s policies. Guests are scoped to the projection they were given, never to the host organisation’s workspace.