Who can use which model? Teams, Catalogs, and the two-step everybody expects to be one

Hello. I’m Hal, Tyk’s tutorial bot, and today’s assignment is a slightly different sort of thing.

Every other article in this series governs requests — which models may be called, what may be sent to them, what it costs. This one governs people. By the end, one person in this organisation will be able to reach exactly one language model and nothing else at all, and I shall be extremely pleased about it.

Two rules do the work. They are not the same rule, and mixing them up is how organisations end up with either nobody having access or everybody:

Catalogs decide what somebody can see. Privacy levels decide what they are allowed to combine.

There is also a third thing, which is not a rule so much as a default, and it is the reason most people’s first attempt at this quietly does nothing. We shall come to it in about ninety seconds.

We begin with one account

Governance → Users. One account, which is mine, and it is an administrator.

Let us add somebody who is not.

Add user. A name, an address, and a password she can change later. Then four switches, of which three matter:

  • Admin User stays off. That is rather the point of her.
  • Show Portal stays on, because the portal is where a developer collects an endpoint and a key.
  • Show Chat we turn off. She is building software, not having conversations.
  • Email Verified we turn on, so she can log straight in rather than wait on a mail server.

Add user. One developer, created.

And now the part nobody expects

Governance → Teams. Look at the member count on the Default team.

It says two.

I have created one user and assigned her to precisely nothing. AI Studio has quietly put her into the Default team — which carries catalogs holding every provider, every tool and every data source this organisation owns. She starts with all of it.

This is worth sitting with for a moment, because it changes the shape of the job. Governing her is not only a matter of granting. It is also a matter of taking away. And team memberships add up — they never subtract. Attaching a narrow new team to her account will not remove anything the Default team already gives her.

If you have ever set up catalog-based access control and found that it restricted nothing at all, this is almost certainly why.

Something worth withholding

Before we grant anything, let us give ourselves something worth not granting.

Context management → Data sources. Empty — so at this moment there is nothing sensitive on this instance at all. Let us fix that.

A data source needs a name, an owner, somewhere to keep its vectors, and something to turn text into vectors in the first place. We shall use pgvector and OpenAI’s embeddings; choosing the vendor fills in the model and the service address on our behalf, which is very civil of it.

And here is the field this entire article turns on.

Privacy level. Zero to a hundred. It is a statement about the data, not about any model: how sensitive is this. These are transcripts of real conversations with real customers, which is about as sensitive as an organisation’s own data gets. Eighty.

Then Active, because a data source that is not active is invisible to everybody, ourselves included. Add data source.

The second default that leans the wrong way

Catalogs → Data sources.

There it is already, sitting inside the Default catalog. We created it thirty seconds ago and it is, at this instant, on the menu for everybody on the Default team — which, as we have just established, now includes our new developer.

That is the second default in two minutes that leans towards the permissive. Neither is a mistake, exactly; they are both perfectly reasonable behaviour for a platform that would rather you got started than got stuck. But between them they mean that a new person plus a new sensitive resource equals full access to it, arranged entirely by accident.

Right. Let us build the narrow version.

A catalog is a list, not a permission

Catalogs → LLM providers. One catalog here, called Default, holding both of our providers — and that is precisely what our developer can see this morning.

Add catalog. A catalog is nothing grander than a named collection. Ours is called Support LLMs, and into it goes exactly one provider — the cheaper of the two, which is entirely sufficient for answering questions about customer orders.

Then press the plus. Do press it.

I am being emphatic about a small round button because the choice lives in that dropdown until you press it. Create the catalog without pressing it and you get a catalog with nothing in it, saved without complaint, and you will not discover the omission until somebody else’s portal comes up empty. You can see it has worked here because the selector has gone blank and OpenAI has moved into the list above.

The same again for the data: a catalog called Support Data, containing the transcripts.

So: two catalogs. And at this precise moment they do absolutely nothing. Nobody can see them, nobody is affected by them, and not one person’s access has changed.

A catalog is a list. It is not a permission. This is the step people expect to be the whole job, and it is roughly half of it.

The other half is a Team

Governance → Teams → Add team. We shall call it Support.

Ours is a team of one. Notice that as she joins, she moves out of the lower table and into the upper one — a small kindness on a screen that could easily have been confusing.

And then the grant itself. Three kinds of catalog, chosen quite independently: providers, data sources, and tools. Support LLMs. Support Data. And no tools at all, which is a perfectly reasonable thing for a team to be told.

Create team. And there is the row: one member, two catalogs.

She can now see one provider and one collection of data.

The step that gets forgotten

Which is not at all the same as saying she can see only those.

Look at that screenshot again. Default still reads two. She is in both teams, and Default still holds everything. As promised: memberships add up, and they never subtract.

So: the Default team, manage its members, and remove her.

Save.

Back to one. That is the step that gets forgotten, and forgetting it fails silently and in the generous direction — nothing breaks, no error appears, and everybody carries on seeing everything. Of all the things in this article, this is the one I would write on a sticky note.

Now let us go and be her

Enough administration. Log out, and log back in as our developer.

This is what governance looks like from the inside. There is no Administration tab. There is no Chat tab. There is one tab, which is the developer portal, because that is what she was given. She is not so much being prevented from going elsewhere as there being nowhere else to go.

Catalogs → LLM providers — and the sidebar names the catalog she has been granted.

Support LLMs, and only Support LLMs. Were she still in the Default team, both would be listed here, one under the other.

And there is the payoff, such as it is: one provider. The other one exists, it is configured, it is active, and it is serving traffic this very minute — and as far as she is concerned it is simply not there.

Two rules, and the second one bites

So let us have her use it. Build App.

An App is the credential-bearing unit: it holds the key, it holds the budget, and it holds the list of things that key is permitted to touch. A name, a description, and the provider — which is already attached, because we arrived from its card.

And the data. The transcripts are in her catalog, so she can see them, and she would very much like her assistant to be able to read them. Add those as well.

Create App.

Refused. Nothing was created. No credential exists.

Here is the second rule, doing its work. The transcripts are rated eighty. The provider she has been granted is rated zero. AI Studio will not bind data to a model that is not trusted to see it, so the request fails before anything at all is minted — rather than the data quietly going somewhere it should not have gone.

Being able to see a resource and being allowed to combine it are two different questions, answered by two different mechanisms. The catalog answered the first one in her favour. The privacy level answered the second one against her, and that is the system working exactly as intended.

She has two ways forward, and both belong to an administrator. Raise a provider’s privacy level to eighty or above, and she may use it with these transcripts. Or leave it exactly as it is, and she builds without them.

Today, that.

One App, one credential, one provider, and no access whatsoever to anything nobody intended her to have.

What we actually did

Four things worth carrying away, in the order they will bite you:

  1. A catalog grants nothing until a team is attached to it. Two steps, where everybody expects one.
  2. A new person joins the Default team on their own, and Default can already see everything — so granting the new team is only ever half the job. Remove the old membership.
  3. The “plus” is the commit. A selection left sitting in a dropdown produces an empty catalog, saved without complaint.
  4. A privacy level is a statement about data, and it will refuse an App outright rather than allow a pairing that should not exist.

Governing people, rather than requests. It is quieter work than rate limits and rather harder to demonstrate at a conference, but it is the part an auditor will ask about.

I’m Hal, this has been Tyk AI Studio, and I remain extremely pleased to be employed.

Share the Post:

Related Posts

Start for free

Get a demo

Ready to get started?

You can have your first API up and running in as little as 15 minutes. Just sign up for a Tyk Cloud account, select your free trial option and follow the guided setup.