Inventory Replicate, Together AI, Fireworks AI and OpenRouter Usage

To inventory what your teams run on Replicate, Together AI, Fireworks AI and OpenRouter, you read each account through its own API with a dedicated credential: the deployments and dedicated endpoints, the fine-tuning jobs and the base models behind them, the licence each model carries, and, for a routing service, which keys exist and which models they called. None of these providers sells a true read-only key, so the credential is an elevated grant even when the reader only ever sends GET requests. The work is deciding which account to read, which key to use, what to keep and what to drop, and how often to read it again.

This post walks through that work for a platform or AppSec engineer who has been asked "what models are we actually running, and where?" It starts with what each provider's own documentation says about its accounts, keys and resources, gives you a template and a set of steps that work with a spreadsheet and curl, and then shows how Safeguard reads the same accounts through its integration cards.

Key takeaways

• An AI inventory that only scans code misses the models your teams run on hosted platforms. Deployments, dedicated endpoints and fine-tunes live in the provider account, not in your repository.
• Replicate, Together AI and OpenRouter document no read-only credential. Fireworks AI's narrowest role, inference user, can still run inference. Plan every inventory key as an elevated grant with an owner, an expiry and a revocation step.
• Read only what the inventory needs. Prompts, completions, prediction inputs and outputs, training files and weight files do not belong in an asset register.
• Safeguard's AI-BOM discovery and AI asset inventory (GA) read Replicate, Together AI and Fireworks AI accounts through integration cards on the Project/Product tab, and record deployments, fine-tunes and model provenance as inventory entries with continuous tests.
• Safeguard's Compliance and GRC suite (GA) reads OpenRouter through Compliance › Connectors with a management API key: members, keys, guardrails, credits and the last 30 completed UTC days of model and provider usage, kept as AI usage evidence.
• Safeguard's policies and gates (GA) act with Block, Warn and Notify, with approval through exceptions. The integration pages describe tests and evidence, not a gate wired to these inventories, so treat the results as monitoring.
• Safeguard sends GET requests only on these connections and documents that no customer data from them goes to third-party LLMs.

The situation

The question usually arrives sideways. A procurement review asks which model providers process company data. An auditor asks for the list of AI systems in scope. A finance colleague sees an unfamiliar line item for GPU hours.

Each of those questions has the same first step: find out what is running. On a hosted model platform, "running" means several different things.

• A deployment or dedicated endpoint. Someone has reserved hardware to serve a specific model, often a specific pinned version, with an autoscaling range. It costs money while it is up and it is reachable by anyone holding a key for that account.
• A fine-tuning job. Someone took a base model, trained it on data they uploaded, and produced a new model. That output model inherits the licence terms of the base model, plus whatever obligations come with the training data.
• A model record. The model itself, with its owner, its version and, where the provider reports one, its licence.
• An API key and its usage. On a routing service such as OpenRouter, the asset that matters is the key: which workspace it belongs to, who created it, when it was last used, which models and providers it reached, and whether it runs under a policy that keeps data out of training and storage.

Code scanning finds SDK imports, which tells you a repository talks to a provider. It does not tell you that a fine-tune trained six weeks ago is still serving production traffic on a dedicated endpoint, or that a key created by someone who left the company is still routing requests. Those facts live in the provider account.

A bad week looks like this. A model provider changes terms, legal asks who is affected, and the answer takes days because the accounts were created by individual engineers on personal sign-ups, the keys were shared in a chat thread, and nobody wrote down which fine-tunes went to production. The goal of this post is to make that answer a lookup.

The rules behind an AI inventory

None of the frameworks below names a specific model provider. They set the expectation that you know which AI systems you run, what they are built from and who supplied them. This section summarises the primary texts; it is not legal or audit advice, and your own counsel and assessors decide what applies to you.

NIST AI Risk Management Framework

NIST released the AI Risk Management Framework (AI RMF 1.0) on 26 January 2023 for voluntary use. Its GOVERN function includes a subcategory, GOVERN 1.6, that calls for mechanisms to inventory AI systems, resourced according to organizational risk priorities. In practice that means an inventory that exists, is maintained, and has someone accountable for it.

On 26 July 2024 NIST released NIST AI 600-1, the Generative AI Profile, which maps suggested actions for generative AI onto the AI RMF. Its suggested actions under GOVERN 1.6 list what a generative AI inventory entry should consider, including data provenance and versioning, the underlying foundation models and their versions, access modes, and intellectual property and licensing considerations. A hosted platform account holds most of those facts.

NIST Cybersecurity Framework 2.0 and SP 800-53

CSF 2.0 keeps asset management in the Identify function. Its asset management outcomes include maintained inventories of software, services and systems the organization manages (ID.AM-02) and inventories of services provided by suppliers (ID.AM-04). A dedicated endpoint on a hosted platform is both: a system your team configured and a service your supplier runs.

NIST SP 800-53 Revision 5 control CM-8, System Component Inventory, asks for an inventory that accurately reflects the system, includes all components within it, and is reviewed and updated at a frequency the organization defines. If your hosted model accounts are inside an authorization boundary, CM-8 is where an assessor will look.

CIS Critical Security Control 2

CIS Control 2, Inventory and Control of Software Assets, asks organizations to actively manage all software so that only authorized software is installed and can execute, and so that unauthorized and unmanaged software is found. A model serving behind a key that nobody owns is unmanaged software in every sense that matters.

OWASP Top 10 for LLM Applications: LLM03 Supply Chain

The OWASP GenAI project's 2025 entry LLM03 treats third-party pre-trained models and data as supply chain risk. The entry lists, among other risks, licensing risk from diverse model and dataset licences and the use of outdated or deprecated models that are no longer maintained. It also discusses fine-tuning adapters such as LoRA as part of the supply chain. A hosted inventory that records base models, fine-tune outputs, pinned versions and licence links gives you the data to act on each of those.

OMB M-25-21 for federal agencies and their suppliers

OMB memorandum M-25-21, dated 3 April 2025, tells US federal agencies to keep updating their annual AI use case inventory and sets out risk management practices for high-impact AI. If you sell to an agency, expect questions that come from that inventory work: which models, which providers, where data goes. Your own inventory is what lets you answer quickly.

What each provider's own docs say about accounts and keys

Before you pick a credential, read how each provider describes its own access model. Everything in this section comes from the provider's documentation.

Replicate

Replicate authenticates API requests with API tokens, and its documentation covers creating, managing and securing them, alongside a section on organizations. Replicate's deployments serve a model on hardware you choose, and the docs cover creating, viewing, monitoring and deleting them.

What matters for an inventory: Safeguard's integration page notes that Replicate documents no token scopes, so a token can do whatever its account can do.

Together AI

Together AI's documentation says API keys are scoped to projects, so a key only has access to the resources within its project. You create a key from the project's API key settings, and you can set an expiration date when you create it or later. The docs warn that anyone holding a key has full access to its project's resources and can spend the credit balance, and they advise rotating keys regularly and revoking unused ones.

Together AI's dedicated model inference serves a model on reserved GPUs and uses the same inference APIs as its serverless models. Dedicated endpoints and fine-tuning jobs are the two things in a Together project that most need an inventory.

Fireworks AI

Fireworks AI assigns each user in an account a role. Its administration page describes an Admin role with full control over resources, users and access, and a Contributor role that can run inference on any resource and manage its own resources but cannot modify resources owned by others. The permission table also lists User and Inference User roles. Service accounts take actions through an API key, cannot sign in to the web interface, and are created and given keys with the firectl command line tool. You manage users and service accounts at app.fireworks.ai/account/users.

OpenRouter

OpenRouter routes requests across many model providers. For administration it offers management API keys, which its documentation says cannot be used to call the completion endpoints and exist only for administrative operations. Management keys operate at the account level, are unscoped across all of an account's workspaces, and for organizations can only be created by Organization Admins.

OpenRouter's Zero Data Retention documentation says ZDR means a provider will not store your data for any period of time, and that you can enforce ZDR globally, per model group, per guardrail or per request. It also notes that a provider's general policy can differ from the policy of a specific endpoint, and that OpenRouter tracks the specific policy for each endpoint.

Step by step: build the inventory with whatever tools you have

These steps work with a spreadsheet, the provider dashboards and curl. They are also the steps Safeguard automates, so doing them once by hand helps you judge any tool, ours included.

1. Find the accounts

Start with money and identity, not code.

1. Ask finance for every recurring charge from a model hosting or routing provider, including card charges on personal expense reports.
2. Ask your identity team whether any of these providers sit behind single sign-on, and pull the member list where they do.
3. Search your code and infrastructure for SDK imports and base URLs. This tells you which repositories call which provider, which helps you find account owners.
4. Ask each team lead directly. Personal accounts created for a prototype are the most common gap.

Record each account as a row: provider, account or organization name, owning team, named owner, billing method, and whether it is an organization account or a personal one.

2. Decide what the inventory records

Use one template across providers so you can compare them. Fill only what the provider actually reports.

The last row matters most. No provider API tells you which human is accountable for a deployment. Your inventory has to.

3. Choose a credential for each account

Use this decision table. It summarises the provider docs above and the Safeguard integration pages.

Three rules apply everywhere.

1. Dedicated, named credentials. Name each one for the inventory reader. When it appears in an audit log, nobody should have to guess what it is.
2. Organization over person. A personal token reads that person's resources and dies when they leave. An organization or service account token reads what the organization owns.
3. Store it in one place. The credential goes into the inventory system or a secrets manager. It does not go into a spreadsheet, a ticket or a chat message.

4. Read, keep and drop

When you read each account, separate the fields you need from the fields the API hands you anyway.

Keep: names, identifiers, versions, base models, hardware, scaling ranges, states, licence links, job statuses, key metadata such as creation time, expiry and last use, and usage totals.

Drop unread: prediction inputs and outputs, prompts, completions, training and validation files, weight file URLs, job logs, and any secret embedded in a resource definition, such as a route key or a third-party integration key on a training job.

An inventory that stores prompts becomes a sensitive data store in its own right.

5. Read on a schedule and keep history

An inventory taken once is a snapshot. Read each account on a schedule your risk calls for, and when an asset disappears, mark it inactive instead of deleting it. The history answers "was this endpoint running in March?" which is a question auditors and incident responders both ask.

6. Turn the inventory into checks

A list becomes useful when you ask questions of it every time it refreshes. A starter set:

• Every serving resource has a named owner.
• Every deployment serves a pinned model version, where the provider supports pinning.
• Every model has a licence your legal team has accepted for its use.
• No key is older than your rotation policy allows.
• No key has gone unused for longer than your threshold.
• No key belongs to someone who has left.
• On a routing service, every key runs under a policy that enforces zero data retention with training off, if that is your requirement.

7. Decide what happens on a failed check

A check that fails needs a route: a ticket, an alert, or an exception with an expiry and an approver. Write that route down before you turn the checks on, or the first week of results becomes a pile nobody owns.

What counts as an AI asset on a hosted platform?

Anything that runs a model on your behalf, or produced a model you run. On Replicate that is deployments, trainings and the models they name. On Together AI it is dedicated endpoints, fine-tuning jobs and the catalog models they use. On Fireworks AI it is the account's own models (uploaded, imported, LoRA add-ons and merged models), deployments and supervised fine-tuning jobs. On OpenRouter, where you do not host anything, the assets are the keys and the models and providers those keys reached.

Serverless calls to a public catalog model are a grey zone. They do not leave a resource behind in your account on most platforms, so an account read will not find them. Usage data and code scanning are how you see them.

Why can't I get a read-only key?

Because the providers do not offer one. Replicate documents no token scopes. Together AI documents no read-only key; any key can run inference and start jobs. Fireworks AI's narrowest role, inference user, views all resources and runs inference but cannot create or change them. OpenRouter's management key cannot call models, but it can create and delete keys and edit guardrails.

What you can control is behaviour and blast radius. Pick the narrowest key the provider offers, scope it to one project or organization, set an expiry, keep it in one store, and use a reader that sends only GET requests. Then record the decision as an accepted risk with an owner.

How often should the inventory refresh?

Often enough that a change shows up before someone asks about it. A daily read suits most teams, and it matches how OpenRouter's activity data works: the API serves only the last 30 completed UTC days, so a reader that runs less often than that loses history. For change-heavy accounts, add an on-demand read before audits and incident reviews.

What about private models nobody deploys?

Replicate documents no way to list your own models directly, so a private model that no deployment or training uses will not appear in an account read. That gap is small in risk terms, since an unused model is not serving traffic, but it matters for licence and IP reviews. Ask model owners to tag or list them, or check them through the dashboard during your quarterly review.

How should usage and spend be treated?

As evidence, not as a finding. OpenRouter's activity shows which models and providers your keys used, with requests, tokens and spend; Together AI's billing usage, where enabled, gives month to date totals. Both answer "which providers process our data?" Neither says whether the use was appropriate. Keep totals and names, never request content.

Who should own the inventory credentials?

The team that owns the inventory, usually platform or security engineering, with the provider account admin creating the credential. On Fireworks AI only an admin can create a service account's key. On OpenRouter only an Org Admin can create a management key. Write down who created each credential, who can rotate it and when it expires.

How Safeguard does this

Safeguard reads these accounts through integration cards. Replicate, Together AI and Fireworks AI feed AI-BOM discovery and the AI asset inventory (GA). OpenRouter feeds the Compliance and GRC suite (GA) through Compliance › Connectors. Each card is switched on per workspace; if you do not see it under Integrations, ask your Safeguard contact.

On every one of these connections Safeguard sends GET requests and nothing else, encrypts the credential at rest, never shows it again after you save it, and documents that no customer data from the integration is sent to third-party LLMs. None of them uses webhooks; the inventory is read when the connection's tests run, on their schedule or when you run them by hand.

The steps below follow the Safeguard docs pages for each integration. The commands are shown exactly as the docs show them; we did not run them for this post.

Replicate

1. Create the token in Replicate. Sign in. For an organization, switch to it in the account menu first. Open replicate.com/account/api-tokens and create a token named "Safeguard (read-only use)". Copy it. Replicate has no CLI for creating API tokens.
2. Connect it in Safeguard. Open Integrations, choose the Project/Product tab (the AI Model filter shows only AI model cards), and click Connect on the Replicate card. Name the connection and paste the token into the API token field.
3. Check access. Save, then click Check access. Safeguard calls the account endpoint with the token and reports which user or organization the token reads, along with a reminder that Replicate tokens cannot be limited to reads.
4. Let the tests run. Safeguard reads the account, its deployments, its trainings, and the model record for each model a deployment or training names.

The calls the docs list:

GET /v1/account
GET /v1/deployments
GET /v1/trainings
GET /v1/models/{owner}/{name}

What lands in the inventory: deployment and model names, versions, hardware, instance range, licence links, training status and base model. The tests cover model provenance, licence risk and pinned model versions.

What Safeguard never reads: predictions, prompts, inputs, outputs, training data and weight files. Safeguard never calls the predictions API, because it returns each prediction's inputs and outputs. The training list returns each training's input, logs and weight URL; Safeguard drops them unread.

The docs advise a token of the organization that owns the deployments, not a personal token with access to other organizations. A user token reads only that user's own deployments and trainings.

Together AI

1. Create the key in Together AI. Sign in and switch to the project you want to inventory. Open the project's API keys, create a key named "Safeguard (read-only use)", and set an expiration date if your policy needs one. Copy the key; Together shows a new key only once.
2. Connect it in Safeguard. Open Integrations, choose the Project/Product tab, and click Connect on the Together AI card. Name the connection and paste the key into the API key field.
3. Check access. Save, then click Check access. Safeguard calls the whoami endpoint and reports the project and organization the key reads. Add one connection per project.
4. Let the tests run. Safeguard reads the project's dedicated endpoints, its fine-tuning jobs, the catalog models they use, and, where available, the organization's month to date usage.

The calls the docs list:

GET /v1/whoami
GET /v1/endpoints?type=dedicated&mine=true
GET /v1/endpoints/{id}
GET /v1/fine-tunes
GET /v1/models
GET /v1/billing/usage   (optional)

The billing usage read depends on a billing usage feature that Together enables per organization. Without it there is no usage entry and no error. When it is on, Safeguard keeps only the month's total cost, the number of line items and the product names.

A legacy API key also works if your account has no projects yet, but it is not scoped to a project and can only be regenerated, not revoked. Prefer a project key.

What lands in the inventory: endpoint and model names, hardware, autoscaling, job status, base and output models, and licences. The tests cover model provenance and licence risk. Safeguard never reads training and validation files, job events, prompts or completions.

Fireworks AI

Fireworks AI is the one provider here where the role you pick changes what Safeguard can check. An inference user key gives you the model inventory. An admin key adds access tests: users, every user's API keys, the audit log and the zero data retention policy.

1. Create a service account and key. As an admin of the account, create the service account and its key with firectl. The Safeguard docs show:

# Inventory only:
firectl user create --user-id "safeguard-inventory" --service-account --role=inference-user
firectl api-key create --service-account "safeguard-inventory"
# Inventory and access tests:
firectl user create --user-id "safeguard-admin" --service-account --role=admin
firectl api-key create --service-account "safeguard-admin"
# Change a role later:
firectl user update safeguard-inventory --role=inference-user

Copy the key and note the account ID. The docs note that the inference user and contributor roles are newer, and that you may need to ask Fireworks support to enable them if firectl refuses the role.

2. Connect it in Safeguard. Open Integrations, choose the Project/Product tab, and click Connect on the Fireworks AI card. Enter the API key and the account ID, with or without the "accounts/" prefix. The Setup steps section shows the firectl commands with your account ID filled in.
3. Check access. Save, then click Check access. Safeguard lists one model, then tries to list every user's API keys to see whether the key is an admin's. With an admin key it confirms both the inventory and the access tests. With an inference user key it confirms the inventory and says the access tests need an admin key.
4. Let the tests run. Safeguard reads the account's models, deployments and supervised fine-tuning jobs.

The calls the docs list for the inventory:

GET /v1/accounts/{account_id}/models
GET /v1/accounts/{account_id}/deployments
GET /v1/accounts/{account_id}/supervisedFineTuningJobs

And, with an admin key, for the access tests:

GET /users
GET /users/-/apiKeys
GET /auditLogs
GET /policySettings

What lands in the inventory: model, deployment and job names, kinds, base models, accelerators, replica ranges, routes, states, and who started each job. It feeds the asset inventory and model provenance tests. Fireworks reports no licence and no model version, so the licence and version pinning tests do not run for it.

Safeguard asks Fireworks for only the fields it needs, so the secrets in a deployment's direct route keys or a job's Weights and Biases settings are not returned. If Fireworks refuses that field list, Safeguard reads the list once without it and drops those fields unread. Datasets, prompts and completions are never read, and deleted deployments are left out.

OpenRouter

OpenRouter is different from the other three. It does not host your models; it routes requests. So the Safeguard card is a compliance connector focused on keys, guardrails and usage, and clicking it opens Compliance › Connectors.

1. Create the management key. Sign in to OpenRouter as an Org Admin and open the Management API Keys page in your account settings. Click Create, name the key Safeguard, set an expiry, and create it. Copy the key; OpenRouter shows it once.
2. Optionally check it first. OpenRouter has no CLI that creates a management key. The Safeguard docs show this call to confirm the key type before you paste it:

curl -s https://openrouter.ai/api/v1/key -H "Authorization: Bearer $OPENROUTER_MANAGEMENT_KEY"

The answer's data.is_management_key must be true.

3. Connect it in Safeguard. Open Integrations, then the OpenRouter card in the AI models group. It opens Compliance › Connectors. Choose OpenRouter, paste the key into Management key and save.
4. Run the tests. The card shows Verified only after a successful read. After that the connector's tests run on their daily schedule, and you can run them by hand from Compliance › Connectors.

The calls the docs list:

GET /api/v1/organization/members
GET /api/v1/workspaces
GET /api/v1/keys
GET /api/v1/guardrails
GET /api/v1/guardrails/assignments/keys
GET /api/v1/credits
GET /api/v1/activity

What the tests check:

• Members matched to your people register: accounts linked, leavers and admin count.
• Keys in every workspace, including disabled and expired ones: key age, keys not used in 90 days based on last use, and keys whose creator has left.
• Guardrails: whether every enabled key runs under a guardrail that enforces zero data retention with model training off.
• Usage evidence: the credit balance and the models and providers used in the last 30 completed UTC days, with requests, tokens and spend per model.

A normal model key will not work: OpenRouter refuses the management reads, and the tests show the error. An OAuth user key is a model key and does not work either. Safeguard never stores key values (OpenRouter never returns them) and never reads prompts or completions.

One nuance from the docs: account-wide privacy settings are not readable through OpenRouter's API. If a key runs under no guardrail that enforces zero data retention with training off, the test asks for an attestation. You can fix it by assigning such a guardrail to the key, or by uploading an attestation of the account settings.

Where the results go

For Replicate, Together AI and Fireworks AI, results appear as AI asset inventory entries and continuous tests. An asset that disappears is marked inactive, not deleted, which gives you the history step 5 asked for. For OpenRouter, results appear as connector test results with evidence, including the model usage summary, in the Compliance and GRC suite, where they can sit next to the controls they support.

Safeguard's policies and gates (GA) act on findings at checkpoints with Block, Warn and Notify, with approval handled through exceptions. The integration pages for these providers describe tests and evidence; they do not describe a gate wired to these inventories, so plan on reviewing failed tests and routing them through your normal ticket or exception process.

Side by side

Rotation and disconnect

The docs give the same pattern for each provider: create the new credential, edit the connection in Safeguard, paste it and save, then delete or revoke the old one. To disconnect, delete the connection in Safeguard first, then delete the credential at the provider. For OpenRouter both steps happen under Compliance › Connectors. For Fireworks AI you can delete the key or the whole service account.

Troubleshooting you are likely to see

• A 401 from the provider. The credential was deleted, revoked, expired or mistyped. Create a new one and update the connection.
• The credential belongs to another account or project. On Replicate, create the token while switched to the owning organization. On Together AI, create the key in the project that owns the endpoints or jobs. On Fireworks AI, check the account ID matches the key.
• The list is longer than Safeguard reads in one run. Safeguard refuses to judge a partial list and asks you to contact support.
• A 403 from OpenRouter. A model key was pasted, or the account is not an organization. Use a management key created by an Org Admin.

What Safeguard does not do

• It does not make the credential read-only. Safeguard only sends GET requests, but the token or key you paste can still do everything the provider allows. On Replicate that includes running models and changing deployments. Treat it as an elevated grant, and own its expiry and rotation yourself.
• It does not read prompts, completions, predictions or training data. That is a design choice, and it means the inventory cannot tell you what data was sent to a model or what the model returned. If you need that, it is a runtime control question, not an inventory one.
• It does not see what the provider does not report. Replicate documents no way to list your own models, so a private model no deployment or training uses is missing. Fireworks AI reports no licence or model version, so those tests do not run for it. OpenRouter serves only the last 30 completed UTC days of activity, and account-wide privacy settings are not readable through its API.
• It does not judge licences for you. The inventory records the licence link or licence the provider reports, and the licence risk test flags models it cannot judge. Whether a licence permits your use is a decision for your legal team.
• It does not assign owners. No provider API says which person is accountable for a deployment. That field in your inventory stays your job.
• It does not shut anything down. A test that finds an unpinned deployment or an unused key reports it. Deleting the endpoint, revoking the key or adding the guardrail happens in the provider account, by someone with authority to do it.
• It does not read accounts you have not connected. Personal accounts, prototype accounts and accounts in other business units stay invisible until someone creates a credential and connects them. Step 1, finding the accounts, is still yours.

Common mistakes

• Using a personal token. It reads only that person's resources on Replicate, it carries that person's role on Fireworks AI, and it stops working the day they leave. Use an organization token or a service account.
• One key across many Together AI projects. Project keys are scoped to one project. A legacy key reads more but cannot be revoked, only regenerated. Use one project key per project and one connection per project.
• An admin key for inventory only. On Fireworks AI the inference user role is enough for the inventory. Use an admin service account only if you want the access tests, and know that an admin key can manage users and keys.
• Pasting a model key into OpenRouter. Only a management key can list keys, credits and activity. A model key fails, and so does an OAuth user key.
• No expiry on the credential. Together AI and OpenRouter let you set one. Set it, and put the rotation date in a calendar the team actually watches.
• Storing request content in the inventory. If your homegrown script logs full API responses, it may capture prediction inputs, training file references or weight URLs. Drop them at read time.
• Deleting vanished assets. If an endpoint disappears and your inventory deletes the row, you lose the answer to "was it running last quarter?" Mark it inactive.
• Treating usage as approval. A model showing up in OpenRouter activity tells you it was used. It does not tell you the use was reviewed. Feed new models and providers into your review process.

FAQ

How do I list all models deployed on Replicate?

Read the account's deployments with an API token of the owning user or organization, then read the model record for each model a deployment names. Each deployment shows the model and pinned version it serves, its hardware and its instance range. Safeguard's Replicate card does this and records the results in the AI asset inventory.

Can I create a read-only Replicate API token?

No. Replicate documents no token scopes, so every token has full access to its account. Use an organization token, keep it in one place, use a reader that only sends GET requests, and rotate it on a schedule.

Does a Together AI API key see every project?

A project API key sees only its own project. A legacy key reads whatever the account can, and it can only be regenerated, not revoked. Create one project key per project you want to inventory.

What Fireworks AI role should an inventory service account have?

Inference user, if you only need the model inventory. It can view all resources and run inference but cannot create or change resources. Use an admin service account only if you also want to review users, their API keys, the audit log and the zero data retention policy.

What is an OpenRouter management API key?

An account level key, created by an Organization Admin, for administrative operations such as managing keys. OpenRouter's docs say it cannot call the completion endpoints. It covers all of the account's workspaces, and it is the only key type that can list keys, credits and activity.

How do I check that every OpenRouter key enforces zero data retention?

List the guardrails and their key assignments, then confirm every enabled key runs under a guardrail with zero data retention on and training off. Safeguard's OpenRouter connector runs that check daily. Account-wide privacy settings are not readable through the API, so keys covered only by account settings need an uploaded attestation.

How far back can I see OpenRouter usage?

The last 30 completed UTC days. Older activity is not available through the API, so read it at least that often if you want continuous history.

Does Safeguard send my prompts or model outputs to an LLM?

No. Safeguard never reads prompts, completions, predictions or training data on these connections, and its docs state that no customer data from these integrations is sent to third-party LLMs.

Why don't I see the Replicate, Together AI, Fireworks AI or OpenRouter card?

Each card is switched on per workspace. Ask your Safeguard contact to turn it on for your workspace.

The steps above stop at knowing what you run and who can reach it. When an inventory turns up a fine-tuning pipeline or serving image built on a vulnerable open source dependency, the next problem is getting a fixed version into that build, which is what the section below covers.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The Claude with Safeguard demo shows Safeguard used from inside Claude through the connector, asking questions about your projects in plain language. Once your hosted model accounts are connected, the same conversational route is a quick way to ask what the inventory holds without opening each card.

Click through it at your own pace, or open it full screen.

The Safeguard CLI demo shows the command line working through a project. Since CLI v11.10.0 the CLI asks before any command that changes something, not before every command. It fits the code side of this work: finding which repositories call which model provider, so you know which accounts to connect.

Click through it at your own pace, or open it full screen.

The desktop app demo shows the same platform in an installed app. It suits the reviewer who checks test results and inventory entries during a weekly or quarterly access review.

Click through it at your own pace, or open it full screen.

Quick check

Related reading: OpenRouter API security, AI-SPM, gateways and the AI-BOM, discovering shadow AI models in production, what an AI model risk registry should track and how to create an AIBOM for AI models.

Download Safeguard at safeguard.sh/download and read the setup guides at docs.safeguard.sh/docs.

Sources

• Safeguard docs: Replicate integration
• Safeguard docs: Together AI integration
• Safeguard docs: Fireworks AI integration
• Safeguard docs: OpenRouter integration
• Safeguard docs: Integrations
• Replicate: API tokens
• Replicate: Deployments
• Together AI: API keys and authentication
• Together AI: Dedicated inference
• Fireworks AI: Service accounts
• Fireworks AI: Users and roles
• OpenRouter: Management API keys
• OpenRouter: Zero Data Retention
• NIST AI Risk Management Framework
• NIST AI 600-1, Generative AI Profile
• NIST Cybersecurity Framework 2.0
• NIST SP 800-53 Rev. 5 OSCAL catalog (CM-8)
• CIS Control 2: Inventory and Control of Software Assets
• OWASP GenAI: LLM03 Supply Chain
• OMB M-25-21

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.