Skip to main content

Setting Up Your Organization: Teams, Roles, and First Policies

You set up your organization in Keeptrusts by establishing ownership before traffic scales: create teams that match real operating boundaries, assign roles with clear review and deployment authority, configure SSO if your identity provider is already in place, and then roll out a small first policy chain through Templates and Configurations rather than trying to solve every governance problem on day one.

Use this page when​

  • You are preparing the first production or pilot rollout of Keeptrusts.
  • You need to decide how members, teams, roles, and policy ownership should map to your organization.
  • You want a practical sequence for getting from first login to a working governed configuration.

Primary audience​

  • Primary: Technical Engineers and Organization Admins
  • Secondary: Technical Leaders, Security, and Compliance owners

The problem​

Most teams can install a gateway faster than they can agree on who owns it. That is where the first rollout usually goes wrong. People focus on the policy YAML, but the real failure mode is often organizational: nobody owns escalations, too many people can deploy configuration changes, spend controls are not mapped to teams, or a reviewer can see alerts but cannot resolve them.

That confusion shows up immediately once traffic begins. A blocked request appears in Events, but the person on call does not know whether to treat it as expected policy behavior or a regression. A new team joins the platform, but its members inherit overly broad permissions because nobody defined roles first. SSO is added late, after people are already manually invited into the wrong groups. Wallet controls are turned on after adoption grows, so costs are visible but not attributable.

The root cause is that platform rollout is being treated as a tooling exercise instead of an operating model exercise. Keeptrusts does not just need users. It needs policy owners, escalation reviewers, configuration deployers, spend owners, and auditors who can export evidence without changing production settings.

The solution​

The most reliable setup sequence is simple.

First, define teams around actual responsibility, not org chart trivia. Teams should reflect who reviews incidents together, who shares wallet funding, and who uses the same policy posture. If engineering, legal, and support all use AI differently, they should not be forced into one team just because they are inside the same company.

Second, assign roles before inviting everyone. Keeptrusts supports a base role model such as owner, admin, member, and viewer, and the console also includes a dedicated roles surface for finer-grained permission control. That matters because the people who can read events are not always the same people who should deploy configurations or change SSO settings.

Third, connect identity early. If your organization uses OIDC or SAML, configure SSO near the start of rollout, not after it. Identity hygiene is part of governance. So are MFA and passkeys in Security Settings.

Fourth, decide how spend is funded. Team-based wallet allocations and budget visibility are easier to introduce before traffic is everywhere.

Fifth, start with a minimal first policy chain. Templates help here because they provide a safer starting point than writing a long policy file from a blank page. Your first deployment should establish basic request hygiene, identity requirements, and auditability. You can add deeper domain controls later.

Implementation​

An effective first-week implementation usually looks like this.

  1. Open Members, Teams and Roles in the console.
  2. Create teams that match operating boundaries, not just departments. A good question is: who should share escalation queues, wallet funding, and policy review?
  3. Invite initial members and assign base roles. Use the broadest role that still fits the job rather than giving everyone administrative access.
  4. Open Settings -> Roles if you need finer permission slices. This is where you can separate capabilities such as reading events, resolving escalations, deploying configurations, viewing billing, or managing org settings.
  5. Configure SSO if your organization already has an identity provider. Keeptrusts supports OIDC or SAML in the team-based access journey, and org:sso is a distinct permission in the console permission model.
  6. Turn on stronger sign-in controls in Security Settings if you require MFA or passkeys.
  7. Decide whether wallets should be managed centrally or allocated by team. If cost control matters from day one, do this before broad adoption.
  8. Choose a starter template or create a new configuration in Configurations.
  9. Validate the YAML, save a version with a clear change detail, and roll it out to the target gateway.
  10. Confirm the first governed requests appear in Events and that reviewers know how to use Escalations.

For many teams, a sensible first policy chain is intentionally small:

policies:
  chain:
    - prompt-injection
    - pii-detector
    - rbac
    - audit-logger

policy:
  pii-detector:
    action: redact

  rbac:
    deny_if_missing:
      - X-User-ID
      - X-User-Role
    require_auth: true

This does not solve every governance requirement, and that is the point. It gives you a first operating baseline: basic attack filtering, sensitive-data handling, request identity requirements, and durable audit coverage.

Before rollout, validate locally or as part of your review flow:

kt policy lint policy-config.yaml

That validation step matters because Keeptrusts is designed around deterministic, versioned configuration changes. The goal is not just to get traffic flowing. The goal is to make sure the first policy is understandable enough that a reviewer can later explain why a request was blocked or escalated.

You should also define the human workflow at the same time.

  • Who can save or deploy a new configuration?
  • Who reviews queued escalations every day?
  • Who can export evidence for an incident or audit?
  • Who owns the team wallet or spend threshold conversation?
  • Who can change SSO or org-level settings?

The console already has the surfaces for those jobs. The setup task is deciding who is responsible for each one.

One practical pattern is to keep policy authorship and policy deployment separate. Engineers may draft and validate changes in Configurations, while a smaller set of admins or approvers deploy them. Another pattern is to let compliance reviewers read events and evidence exports without granting them configuration or token management access. Keeptrusts supports that separation because console access and runtime policy are not the same thing.

Finally, do not skip the first end-to-end exercise. Once the initial setup is done, send a governed request, confirm it appears in Events, and have someone walk through how they would resolve an escalation if one occurred. A platform is not really onboarded until the people who will operate it have touched the actual workflow.

Results and impact​

Organizations that set up teams, roles, and first policies in this order usually avoid the most common rollout mistakes. Escalations have an owner from the start. Configuration history is attributable. SSO does not become a cleanup project later. Wallet control maps to actual teams instead of becoming a finance-only concern. Reviewers can access evidence without being over-privileged.

This also makes the first month of adoption less chaotic. When a new team joins, you already know which role pattern to apply and which template or configuration path they should use. When policy volume grows, you already have a separation between authors, deployers, and reviewers. When a regulator or customer asks how your AI platform is governed, you have a concrete answer that includes identity, review, policy versioning, and evidence export rather than just a list of controls.

Perhaps most importantly, a small first policy chain gives you a stable baseline. If block rates change after later policy additions, you know what changed. If spend increases, you already know which team and wallet scope owns that activity. If an escalation queue grows, you are not simultaneously discovering who the reviewers are supposed to be.

Key takeaways​

  • Set up organizational ownership before expanding policy complexity.
  • Use teams to reflect shared review, spend, and policy responsibility.
  • Assign base roles first, then add finer-grained permissions where needed.
  • Configure SSO and stronger sign-in controls early if your identity stack already exists.
  • Start with a minimal first policy chain that establishes identity, redaction, and auditability.

Next steps​