Skip to main content

​
What this is for

Every machine running the Guardway agent gets its own gateway API key, created automatically the first time that machine checks in. That is what gives you per-machine revocation and per-machine spend attribution — you can cut off one laptop without touching any of the others. What it did not give you was a way to say what those keys are allowed to do. Which models they can call, how fast, how much they may spend, when they stop working — all of it had to be set on each key by hand. At 1,000 endpoints that is 1,000 edits, and every one of them can drift. An Access Profile is a named, reusable set of exactly those constraints. A policy selects a profile once, and every machine that policy covers inherits it. Change the profile and every key under it changes with it — one edit instead of one per machine. Profiles are managed in Configuration → Access Profiles.

​
Options

​
What a profile contains

Every limit is per key, not per fleet. A profile with a 200 requests/min limit gives each machine 200 requests/min, and a 50budgetgiveseachmachine50 budget gives each machine 50 — the profile is the rule, not a shared pool. Fleet-wide spend is on Dashboard → Spend.

​
Unrestricted (default)

Every policy starts on Unrestricted (default). That is not a profile you can edit — it means no constraints, which is exactly how endpoint keys behaved before Access Profiles existed. Leave a policy on it and nothing about that policy’s machines changes.

​
How to configure

​
Create a profile

1

Open Configuration → Access Profiles

Open Configuration → Access Profiles from the dashboard sidebar and click New profile.
2

Name it after the population, not the machine

Profiles are reused across policies. Contractors, Build agents, and Standard laptop age well; a single machine’s hostname does not.
3

Set the constraints

Add Allowed Models (leave empty to allow all), Requests/min, Tokens/min, and a Budget (a lifetime cap per key). Set the Expiry (days) window, or keep the default of 90.
4

Save

The profile appears in the list with a reference count — how many policies and how many live keys are currently using it. A brand-new profile shows zero of each until you assign it.

​
Assign a profile to a policy

1

Open the policy the machines follow

Open the policy editor for the machines you want to constrain and go to its Posture pane.
2

Pick an Access Profile

Choose the profile from the Access Profile picker. The first option, Unrestricted (default), is the no-constraints behavior described above.
3

Publish

Publish the policy. Machines pick up the change at their next policy refresh — allow up to six hours for the whole fleet, since an agent refreshes a cached policy once it is older than that. Each machine’s existing key is updated in place; the machine does not need a new secret and nothing on the endpoint has to be restarted.
4

Verify

Open Configuration → API Keys → System-managed and confirm the machines now appear grouped under the profile name. Every publish and profile change is recorded in the Audit log.

​
Change a profile

Edit the profile and save. The change applies to every key under that profile at once, and the machines using them see the new limits at their next policy refresh (up to six hours). You do not re-publish the policies and you do not touch the keys. This is the whole point of profiles: tightening a fleet of 1,000 endpoints to one model family is one edit, not a thousand.

​
Managed by profile

Keys created for machines no longer sit in the same list as the keys your team issues by hand. Configuration → API Keys has two tabs:
  • Human — the keys your team creates for applications. Unchanged.
  • System-managed — the keys Guardway created for endpoint machines, grouped by the profile they follow.
System-managed keys are view and revoke only. There is deliberately no edit form for them: each machine re-applies its profile every time it checks in, so a hand-edit would silently revert at that machine’s next policy refresh. Every row says so. To change what a machine’s key can do, change its profile — or point that machine’s policy at a different profile. Per-machine exceptions are a second profile, not a hand-edit. Keys that were created before Access Profiles existed, or whose machine has not checked in since you assigned one, are grouped under Unprofiled. They keep working exactly as before and move into their profile’s group at the next check-in.

​
Revocation and re-mint

Revoking a system-managed key takes effect immediately — the gateway stops accepting it. What happens next depends on the machine:
  • The machine is still active. It creates a fresh key at its next check-in — same profile, same limits, new secret. Revocation is a rotation.
  • The machine is gone (decommissioned, wiped, agent removed). Nothing comes back. Revocation is a removal.
Expired keys behave the same way: an active machine replaces its own expired key at the next check-in without anyone doing anything.
Because revocation on a live machine is a rotation, it is the right tool for a suspected leaked secret — and the wrong tool for taking a machine’s AI access away. To do that, change the machine’s policy or its profile.

​
Expiry, and what shortening it does

Expiry is counted from when each key was created, not from when you last edited the profile. Editing a profile therefore never extends the life of the keys already under it.
Lowering the expiry window re-keys the fleet. Because expiry is measured from each key’s creation date, shortening the window can put existing keys past their expiry the moment you save — every machine under that profile then replaces its key at the next check-in. Nothing breaks and no machine loses access, but it is a real fleet-wide rotation, so the dashboard asks you to confirm before it commits the change.

​
Deleting a profile

A profile that is still in use cannot be deleted. If any policy selects it, or any live key follows it, the delete is refused and the dashboard tells you how many of each are holding it. Remove the references first: point those policies at another profile (or at Unrestricted (default)), then revoke the keys that remain or let them expire. Then delete.
A missing or misconfigured profile never takes AI offline. If a policy points at a profile that can no longer be resolved, machines keep the configuration they already have rather than losing access — and Guardway never silently downgrades them to an unconstrained key. See fail-open.

​
Permissions

Owner and Admin can create, edit, and delete profiles, assign them on a policy, and revoke system-managed keys. Read Only can see profiles, their limits, and which keys follow them, but no write action is offered.
  • API Keys — the two tabs, and the keys your team issues by hand.
  • Models — the model inventory an Allowed Models list draws from.
  • Dashboard → Spend — per-key and fleet-wide spend, including endpoint machines.
  • Audit log — profile creates, edits, deletes, and key revocations.
  • Guardway CLI — the agent that runs on each machine.