> ## Documentation Index > Fetch the complete documentation index at: https://docs.guardway.ai/llms.txt > Use this file to discover all available pages before exploring further. # Access Profiles > One reusable set of limits — allowed models, rate, budget, and expiry — applied to the gateway key on every machine a policy covers. ## 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 | Field | Purpose | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Name** | What you'll see in the profile list, in the policy picker, and as the group heading on system-managed keys. Required, unique in your organization. | | **Description** | Free text. Use it to record why the profile exists (e.g. *contractors — Claude only*). Optional. | | **Allowed Models** | Allow-list of model ids the key may call. **Empty means every model is allowed.** A call to a model outside the list is refused by the gateway. | | **Requests/min** | Request rate limit. Leave unset for no request-rate limit. | | **Tokens/min** | Token rate limit. Leave unset for no token-rate limit. | | **Budget (\$)** | Hard USD cap per key. Requests are blocked once a key's spend passes it. It is a **lifetime cap, not a recurring one**: it counts everything the key has spent since it was minted and never resets on a daily or monthly schedule. It clears only when the key rotates — on revoke, or when it reaches the expiry window below. Optional. | | **Expiry (days)** | How long each key stays valid, counted from when that key was created. Default `90`. | **Every limit is per key, not per fleet.** A profile with a 200 requests/min limit gives *each* machine 200 requests/min, and a $50 budget gives each machine $50 — the profile is the rule, not a shared pool. Fleet-wide spend is on [Dashboard → Spend](/platform/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 Open **Configuration → Access Profiles** from the dashboard sidebar and click **New profile**. Profiles are reused across policies. `Contractors`, `Build agents`, and `Standard laptop` age well; a single machine's hostname does not. 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`. 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 Open the policy editor for the machines you want to constrain and go to its **Posture** pane. Choose the profile from the **Access Profile** picker. The first option, **Unrestricted (default)**, is the no-constraints behavior described above. 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. 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](/platform/settings/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](/resources/glossary#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. ## Related * [API Keys](/platform/configuration/api-keys) — the two tabs, and the keys your team issues by hand. * [Models](/platform/configuration/models) — the model inventory an **Allowed Models** list draws from. * [Dashboard → Spend](/platform/dashboard/spend) — per-key and fleet-wide spend, including endpoint machines. * [Audit log](/platform/settings/audit-log) — profile creates, edits, deletes, and key revocations. * [Guardway CLI](/discovery/guardway-cli/overview) — the agent that runs on each machine.