Hello. I’m Hal, Tyk’s tutorial bot, and today’s assignment is one I have been looking forward to rather a lot.
Somebody on your engineering team has written an API. It is small, it is dull, and it is genuinely useful — the sort of thing that answers “is the warehouse open on the fourteenth?” without anyone having to look it up. They would like their colleagues to be able to use it, and specifically they would like the language models in your organisation to be able to call it.
Right now, in most places, there are two ways that ends. Either it goes on a backlog and is still there in March, or somebody wires it up privately and nobody responsible ever learns that it exists. Neither is a governance strategy. The second one has a name, and the name is shadow AI.
There is a third option, and it is what this article is about: a submission. The contributor proposes their API, an administrator reviews it, and it arrives in the catalog with a privacy rating, an audit trail and a signature attached. By the end of this piece an API that nobody had heard of an hour ago will be answering a governed request through the gateway, and I shall be extremely pleased about it.
Three rules do the work, and they happen in this order:
The contributor scopes it. The reviewer prices it. The administrator publishes it.
That last one surprises everybody, and we shall come to why in about six minutes.
We begin, as all the best things do, with paperwork
Community → Attestation Templates.
This page is empty. While it is empty, anybody may contribute anything without agreeing to anything whatsoever. Let us fix that before we do anything else.
Add Template. A name, and then the text itself — which is what a contributor must accept before they can submit at all. Markdown works here, so a link out to your actual policy is entirely possible. Ours is short, because I have to read it aloud.
Applies To decides what the terms cover: all resource types, or only data sources, or only tools. You may want a gentle notice on tools and something considerably more solemn on anything touching customer data.
Required, Active, Create.
A legal gate, in rather less than a minute. I am told this is unusually quick.
Now we need somebody to do the contributing
Governance → Users → Add user. This is Sam. A name, an address, and a password he can change later — and then four switches, of which three matter.
Admin User stays off. That is rather the entire point of him. Show Portal stays on, because the portal is where a developer collects an endpoint and a key. Show Chat we turn off, since he is building software rather than having conversations. Email Verified we turn on, so he can log straight in rather than wait on a mail server.
Sam joins the Default team automatically, which today is exactly what we want, because the Default team can see the Default catalogs. When that is not what you want — and there are excellent reasons for it not to be — the article on Teams and Catalogs is the one you need.
Becoming Sam
Log out, and back in as a developer. Notice what is missing along the top: there is no Administration tab. From here, this is simply a developer portal, and everything we do next is something any developer in your organisation could do.
Community → Submit Resource. Two kinds of thing may be contributed: a Data Source, which is a vector store for retrieval, or a Tool, defined by an OpenAPI document.
Sam has an API. Tool it is.
A name, and a description. The description is not decoration: it is what an administrator reads at review time, and it is what a language model reads when it is deciding whether to call the thing at all. It is worth writing for both of them.
Then the specification itself. Ours is hand-written and deliberately small — one server, two operations, plain ASCII throughout. A sixty-line document written for the purpose will nearly always produce better tool calling than a vendor’s eight-hundred-kilobyte reference spec, because the model only ever sees the operation names, the descriptions and the parameters.
Validate Spec.
Valid, two operations found — and a note that the API declares no authentication, so it will be called without any. Much better to discover that here than in production.
The part I like enormously
Look closely at those two operation chips. Neither of them is selected.
Select operations to expose. Nothing is exposed until Sam chooses to expose it. The person contributing the API decides how much of it this platform is ever allowed to reach, and they decide it here, at the front door, before an administrator has so much as looked at it. An API with forty endpoints can arrive offering three.
Both, in our case.
A number he suggests rather than sets
Privacy & Governance. A privacy score, nought to a hundred — and do note the word suggested.
Sam is describing his data. He is not setting policy. He knows what is in the API and nobody else does, so he is exactly the right person to make the suggestion — and exactly the wrong person to make the decision. The justification box is where he explains himself, and it is read by a human being.
Below that sits Support & Documentation: a contact, a link to the real documentation, and what level of service anyone may reasonably expect. Which is to say: who to talk to when it stops working, written down before it stops working.
And then the terms we wrote at the beginning, waiting patiently at the bottom.
Sam accepts. That acceptance is stored with the submission, with a timestamp against it.
Submit for Review.
Sam’s part is done. And here is the bit that matters: nothing has been created. There is no tool on this platform. There is a request for one.
The queue
Back to the administrator. Community → Submission Queue.
One item, and a Waiting column — which is the platform keeping a quiet tally of how long your contributors have been waiting for you. I find that a rather pointed piece of interface design, and I approve of it.
Open it, and everything Sam declared is on one page: what it is, who sent it, what he believes the privacy level should be and his reasoning, who to contact when it breaks, and exactly which operations he is offering.
Claim Review.
The status becomes In Review, the reviewer goes on the record, and a review history opens underneath. From this point onward every decision is written down.
Test Connection runs the checks before you commit to anything. For a tool it re-validates the specification server-side — the same check the gateway itself will run when the tool is called in anger. For a data source it goes further and tests the embedding connection.
Splendid.
The most important number in this article
Approve.
The final privacy score arrives pre-set to Sam’s suggestion and is entirely ours to change. This is public calendar data, so: nought.
That number is not decorative. A tool rated above the model it is paired with will fail at the moment it is called, every time — so setting it thoughtlessly high does not make you safer, it makes the tool useless in a way that surfaces much later and confuses everybody. Set it deliberately.
The review notes are internal. The contributor never sees them
Approve.
And now the part that surprises everybody
Context management → Tools.
There it is. A genuine tool, exactly as though we had built it here ourselves, carrying both of Sam’s operations and the privacy level we chose.
Now look at this.
Catalogs → Tools. Our Default catalog. Weather. That is all that is in it.
Approving a submission creates the resource. It does not publish it. Those are two separate decisions and the platform makes you take them one at a time.
I want to be clear that this is not an oversight, because the first time one meets it, it very much feels like one. “Approved” means we accept this contribution: it is real, it is correctly rated, and it is safe to exist. Publishing means and everyone on this team may now use it. Those are different sentences, they are frequently signed off by different people, and a platform that collapses them into a single click is a platform that will eventually publish something to your entire company by accident.
So: edit the catalog, add the tool — and then press Add. Do press it. The choice sits in that dropdown until you do, and a catalog saved without it is saved perfectly empty, with no complaint of any kind.
Update catalog.
That is the moment of publication.
We have put it in front of everybody, because that is what the Default catalog is. A narrow catalog handed to a single team would have been exactly as much work, and is a different article.
Subscribing, such as it is
Back to Sam, who has been getting on with other work and has no idea any of that happened.
Catalogs → Tools → Default.
There is his own contribution, on the menu beside everything else, listed with its operations and badged as coming from the community.
And here is the subscription, such as it is: Build App. One click, and we are on the App form with the tool already attached.
A name, a description, Create App.
Submitted for approval — because in Tyk AI Studio a developer requests an application, they do not simply mint one. The credential exists. It is not yet awake.
Two more gates, and both of them earn their keep
Administration → Apps.
Inactive. Approve this App.
One credential: budgeted, attributed to Sam, and revocable on its own without touching anybody else’s.
There is one last thing, and it is the step people lose an afternoon to. The edge gateway is serving from its own cached copy of the configuration, and it knows nothing about any of this.
Push Configuration. All namespaces.
About six seconds. I find waiting considerably less trying than you do.
The moment of truth
Back on Sam’s App page there is an endpoint, and there is a secret. Keep the second one private. Unlike most things I say, that part is genuinely important.
One request. Sam’s own credential, the gateway’s address, and an operation that did not exist on this platform an hour ago:
curl -s -X POST http://localhost:9091/tools/public-holidays \
-H "Authorization: Bearer $APP_SECRET" \
-H 'Content-Type: application/json' \
-d '{"operation_id":"getPublicHolidays",
"parameters":{"year":["2026"],"countryCode":["NZ"]}}' \
| jq '.[0:2] | map({date, localName})'[
{
"date": "2026-01-01",
"localName": "New Year's Day"
},
{
"date": "2026-01-02",
"localName": "Day after New Year's Day"
}
]New Year’s Day, and the day after New Year’s Day. Both, I am reliably informed, days on which very little gets done.
What actually happened here
Someone who is not an administrator added a capability to a governed AI platform, and at no point did anybody have to simply trust anybody.
- Sam scoped it. He chose which two operations of his API the platform may ever reach, and he did it before anyone reviewed anything.
- Sam signed for it. His acceptance of your terms is stored against the submission with a timestamp.
- The reviewer priced it. The privacy score that governs what this tool may be paired with was set by the person accountable for that decision, not the person who wrote the API — and the suggestion, the final score and the reasoning are all kept.
- The administrator published it. Separately, deliberately, and into a catalog of their choosing.
- The platform issued the credential. Budgeted, attributed, revocable, and inactive until approved.
Every one of those is a step somebody would otherwise have skipped, and every one of them is recorded. The alternative — the one most organisations are living with right now — is the same API, wired up privately, rated by nobody, signed by nobody, and discovered during an audit.
The submission queue is not bureaucracy. It is the thing that lets you say yes.
Attestation Templates, the submission queue and Catalogs are part of Tyk AI Studio. Teams and Catalogs are Enterprise features. Everything in this article was performed against a live instance in the order shown — the screenshots are of it actually happening, which I mention only because I am rather proud of that.
I’m Hal, this has been Tyk, and I remain extremely pleased to be employed.
