Security and governance

Keep AI access scoped and accountable

Safety here is operational, not aspirational. Scope, credentials, validation, approval, and audit are explicit controls you configure for every connection, so an AI client can only see what you expose, act as the person asking, and write only what passes your rules. This page walks through each control and shows what it produces.

  1. 1

    Scope what AI can see

    Console -> Configure -> Exposure

    Exposure is an allow list, not a filter applied after the fact. For each connection you choose which entities, fields, and operations are visible, and everything else stays hidden. When a connection should never change data, set it to read-only and no write tools are generated at all.

    What you'll seeScoped

    The connection is reduced to exactly what you selected:

    • Only the chosen entities and fields appear to the model; the rest are not discoverable
    • Only the chosen operations are callable, and a read-only connection exposes no writes
    • Anything outside the selection is treated as if it does not exist
  2. 2

    Keep credentials in the vault

    Console -> Configure -> Credentials

    The connection references a credential held in the vault; it does not carry the secret itself. DataTether uses that reference to authenticate to the source system on the server side. The credential is never returned to the model, the client, or a tool response.

    What you'll seeVaulted

    Credentials stay sealed behind the connection:

    • Tools call the source system using a vault reference, not a literal secret
    • The username, password, or token is never exposed to the model or the client
    • Rotating a credential in the vault updates every tool that uses it
  3. 3

    Enforce least privilege

    Console -> Configure -> Access

    Every call runs under the access of the person making the request, not a shared service identity. That means row-level security and source permissions still apply on the source system, exactly as they would for that user signing in directly. DataTether does not run as a superuser on your behalf, so an AI client can never reach data the requesting user could not reach themselves.

    What you'll seeScoped to user

    The user's own permissions are the ceiling:

    • Each call carries the requesting user's identity through to the source system
    • Row-level security and field authorizations stay active on every read and write
    • No request is elevated beyond what that user is already allowed to do
  4. 4

    Validate writes before they run

    Console -> Configure -> Validation

    Writes are checked against rules you set per entity before anything reaches the source system. You can validate field existence and data types, require fields, control nullability, and keep keys immutable. A strict mode tightens enforcement, allowExtraFieldsdecides whether unknown fields are permitted, and onValidationError sets what happens when a check fails. Invalid writes are rejected at the boundary, so a malformed change never lands.

    What you'll seeRejected
    validation = {
  validateFieldTypes  : true,
  requiredFields      : ["SalesOrderType", "SoldToParty"],
  nullable            : { "PurchaseOrderByCustomer": false },
  keyImmutable        : true,
  strictMode          : true,
  allowExtraFields    : false,
  onValidationError   : "reject"
}

// Invalid writes are rejected before they reach the source system:
{
  "status": "rejected",
  "errors": [
    { "field": "SoldToParty",       "rule": "required",  "message": "Required field is missing" },
    { "field": "NetAmount",         "rule": "type",      "message": "Expected number, received string" },
    { "field": "InternalRiskScore", "rule": "extra",     "message": "Field not allowed (allowExtraFields: false)" }
  ]
}
  5. 5

    Gate sensitive actions behind approval

    Console -> Configure -> Approvals

    For actions that warrant a human in the loop, the write does not execute on request. It pauses and waits for a named approver, who can release it to run or reject it. A released request proceeds under the original user's access and validation rules; a rejected request is blocked and never touches the source system.

    What you'll seeApproval required

    A sensitive write becomes a request, not an action:

    • The call pauses and is held for review instead of running immediately
    • An approver can release it to proceed, or reject it
    • A rejected request is blocked, and nothing is written to the source system
  6. 6

    Audit every action

    Console -> Activity

    Actions are logged and traceable, so there is always a record of what happened. Each entry captures who made the request, what they did, and when, which gives reviews, approvals, and incident response a single trail to follow rather than guesswork after the fact.

    What you'll seeLogged

    Every action leaves a traceable record:

    • Who: the user whose access the call ran under, and any approver involved
    • What: the tool that ran, the target entity, and the outcome
    • When: a timestamp you can line up across reads, writes, and approvals

Related