Cresec

What is a governed AI tool?

By the Cresec team · Published · Updated

A governed AI tool is a tool — often built by someone outside IT — that a whole team can use safely, because it follows a few simple rules about who is using it and what it may do.

The defining property: code decides the action

In a governed tool, code decides which actions run and who receives what the tool sends, before the tool reads any untrusted text. A model may classify a request or write a draft, and it can be fooled into writing the wrong words. It can’t choose a different action or recipient, because that choice was never the model’s to make.

The five rules

  1. Each person is themselves. People sign in with their company account. The tool acts as the person using it, never as its builder.
  2. Upstream credentials have a defined home. On Cresec’s mediated path, the tool holds no upstream app credential. The gateway, vault, identity session and application data still require protection.
  3. Bounded actions by default. Prepare before sending, and grant more per person and tool. Creating a mailbox draft is itself an upstream write; name exact actions and scopes.
  4. Attributable records and explicit gaps. Verify integrity under documented trust assumptions. Separately prove coverage; a missing action is not automatically detected by a valid signature.
  5. Explicit failure behavior. Cresec refuses live governed calls, with an error the tool can retry, when the control service is unavailable. Cached display and live read access are different.

How it differs from other approaches

A personal tool may rely on one person’s login. Before sharing, check whether the existing platform can give teammates suitable access.

A shared-account tool lets the team use it, but everyone acts as one person, with no way to tell who did what.

A tool adapted by IT can retain the useful workflow while addressing its controls. Neither rebuilding nor using a gateway automatically makes an application safe.

A governance layer may let you retain the original workflow, depending on its host, calls and identity model. Compatibility needs assessment.

Connecting a tool is only one part of governing it

For an assistant-based workflow, Claude Code’s maintained MCP guide is a useful starting point for configuration, authentication and shared project settings. The original remote MCP announcement on X provides historical context; use the current documentation when evaluating behavior. Use these sources to prepare the configuration and authentication questions for your workflow review.

Who it’s for

People in sales, recruiting, customer success, operations and finance who have built something their team wants; and the IT and security teams who review it. Evaluate Cresec only for a specific supported gap. The FAQ covers what to check for each capability.

Sources and further reading

References reviewed . Documentation supports feature descriptions; community experiences and historical announcements provide context, not proof of current capability.

See it fail against a design, not a detector.

One poisoned ticket, two designs of the same routine, and a model assumed fully fooled in both.

Watch the attack fail