Store secrets
Store a password or API token once, then use it by name. Its value is stored securely and never shown again.
A secret is a credential: an API token, a webhook auth secret, a connector password. Kortecx uses one only at the moment your App reaches an outside service, and at no other moment.
Kortecx stores secrets per workspace, in a managed secret store: another workspace cannot list, overwrite, remove or use yours. You put a value in once, under a name. From then on, everything refers to the name.
The value is write-only. You send it on the way in and it is never sent back out — not to you, not to a model, not to a log or a run record. If you forget a token, you do not read it back from Kortecx; you get a fresh one from wherever it came from and set it again.
Store one
In an org, only an owner or admin can store or remove a secret. A member can read the names, and nothing more.
Set the value
Pick a name you will recognize later. Names may be 1–255 characters of
A-Z a-z 0-9 _ . -.
Setting a name that already exists overwrites it. There is no separate "rotate" step — you set the new value under the same name and every reference follows.
Check what is stored
Listing returns names and timestamps, and nothing else. There is no request in the system that returns a secret's value.
Remove one
Removal is a write, so the same people who can set can remove.
Where the name gets used
A stored secret does nothing on its own. It becomes useful when something needs to authenticate.
A connection. A connection is an outside tool server the runtime dials.
The connection record stores the string GITHUB_TOKEN. When the runtime
dials that server it looks the name up, injects the value into that one call, and
drops it.
Registering a connection dials the server straight away, so store the secret first and add the connection second — otherwise the registration is refused, because the secret it names is not stored yet.
An app's agentic loop. When an app lets a model choose the tool to fire, the run carries a fixed set of secret names it is allowed to resolve. Before any tool call, the runtime checks that what the call asks for is inside what the run was granted; anything outside it is refused before it happens.
When you read the run back afterwards, you see which tools each step ran and how many times, and how many of its turns were refused. Never a secret value. See seeing what happened.
How a name resolves
When the runtime needs the credential, it reads the value your workspace stored under that name, at the moment of the call. A name your workspace has not stored resolves nothing.
The store may be unavailable
If the secret store cannot be reached, Kortecx says so (secrets_unavailable)
rather than pretending the write succeeded.
Why the value never travels
Everything the runtime writes down — a run record, a step result, an observability record, the text a model sees — carries the secret's name. The value is resolved as late as possible, at the moment of the outbound call, and discarded straight after.
That is what makes the write-only rule enforceable rather than aspirational: if the value is only ever held for the duration of one network call, there is no place for it to leak into.
The list of names, on the other hand, is deliberately visible. Knowing which credentials your workspace holds is a governance question — you should be able to answer it without seeing a single secret.
What this is not
Secrets are kept per workspace: another workspace cannot list, overwrite, remove or use yours. There is no rotation policy beyond setting a new value under the same name.