🔒 Aisle Security Analysis

We found 2 potential security issue(s) in this PR:

1. 🟡 Plugin-controlled cfg enables credential steering in runtime.modelAuth wrappers

Description

createPluginRuntime() exposes runtime.modelAuth.getApiKeyForModel() / resolveApiKeyForProvider() as wrappers around the raw auth helpers, but the wrappers forward a plugin-supplied cfg object directly into the auth pipeline.

This undermines the stated goal of preventing credential steering:

• The wrapper strips agentDir/store/profileId/preferredProfile, but still forwards cfg.
• The raw resolver uses cfg to influence which auth profile is selected:
  • resolveApiKeyForProvider() calls resolveAuthProfileOrder({ cfg, ... }).
  • resolveAuthProfileOrder() consults cfg.auth.order and cfg.auth.profiles to build/override the candidate order.
  • Therefore a plugin can supply a crafted cfg to bias selection toward a particular stored profile for a provider (credential steering), despite profileId/preferredProfile being stripped.
• Additionally, if stored credentials use keyRef/tokenRef SecretRefs, resolveApiKeyForProfile() uses cfg ?? loadConfig() as the configuration for SecretRef resolution; a plugin-controlled cfg.secrets.providers can change the file/exec/env provider configuration used during secret resolution.

Vulnerable code (wrapper forwarding plugin-controlled cfg):

getApiKeyForModel: (params) =>
  getApiKeyForModelRaw({ model: params.model, cfg: params.cfg }),
resolveApiKeyForProvider: (params) =>
  resolveApiKeyForProviderRaw({ provider: params.provider, cfg: params.cfg }),

Raw signatures showing additional steering inputs exist (even if not forwarded):

• resolveApiKeyForProvider(params: { provider; cfg?; profileId?; preferredProfile?; store?; agentDir? })
• getApiKeyForModel(params: { model; cfg?; profileId?; preferredProfile?; store?; agentDir? })

Impact: In a threat model where plugins are less trusted than core, a plugin can influence which stored credential/profile is used (and potentially the SecretRef resolution configuration), contrary to the wrapper’s security comments.

Recommendation

Do not accept arbitrary cfg from plugins for credential resolution.

Options (in increasing strictness):

1. Ignore plugin-supplied cfg entirely and use only host/runtime config:

import { loadConfig } from "../../config/config.js";

modelAuth: {
  getApiKeyForModel: ({ model }) => getApiKeyForModelRaw({ model, cfg: loadConfig() }),
  resolveApiKeyForProvider: ({ provider }) =>
    resolveApiKeyForProviderRaw({ provider, cfg: loadConfig() }),
}

2. If plugins must influence behavior, deep-pick an allowlist of safe fields and explicitly exclude auth.order, auth.profiles, and all secrets.* configuration (to prevent profile steering and SecretRef provider reconfiguration).

3. For multi-agent isolation, pass a trusted agentDir sourced from the core runtime/request context (not from plugin input), and never allow plugins to override it.

Also add behavioral tests proving that supplying cfg.auth.order/cfg.auth.profiles from a plugin does not affect the selected profile.

2. 🔵 Plugins can retrieve raw provider API keys via runtime.modelAuth without authorization

Description

createPluginRuntime() now exposes runtime.modelAuth.getApiKeyForModel() and runtime.modelAuth.resolveApiKeyForProvider() to all loaded plugins.

Security impact:

• These helpers return ResolvedProviderAuth, which includes a raw apiKey?: string field.
• Any plugin can request credentials for any provider name it supplies (e.g. "openai", "anthropic", etc.).
• There is no authorization layer binding allowed providers/models to a plugin’s manifest (openclaw.plugin.json has a providers field, but it is not enforced here).
• Plugins run in-process with the Gateway (per docs), are typically able to perform network I/O, and therefore can exfiltrate resolved credentials.

Vulnerable code:

modelAuth: {
  getApiKeyForModel: (params) =>
    getApiKeyForModelRaw({ model: params.model, cfg: params.cfg }),
  resolveApiKeyForProvider: (params) =>
    resolveApiKeyForProviderRaw({ provider: params.provider, cfg: params.cfg }),
},

And the returned type includes the secret:

export type ResolvedProviderAuth = {
  apiKey?: string;
  ...
}

While the wrappers strip agentDir/store/profileId steering, they still expose cross-provider key lookup, which is sufficient for credential theft by a malicious or compromised third-party plugin.

Recommendation

Do not return raw long-lived provider secrets to plugins by default. Prefer a brokered/capability-based design:

• Option A (recommended): broker requests: expose a method that performs provider API calls on the plugin’s behalf without ever returning the API key.
• Option B: enforce provider allowlists: restrict provider/model resolution to the plugin’s declared manifest.providers (and/or explicit plugins.entries.<id>.allowedProviders) and require explicit admin opt-in.
• Option C: return opaque handles: return an opaque auth handle scoped to a provider and plugin, usable only with runtime-brokered calls.

Example (enforce allowlist + avoid returning keys):

​// runtime creation: pass pluginId into runtime calls or bind per-plugin runtime
resolveProviderAuth: async ({ pluginId, provider, cfg }) => {
  if (!isProviderAllowedForPlugin(pluginId, provider)) {
    throw new Error("provider not allowed for this plugin");
  }
  ​// return non-secret metadata only
  const { mode, source } = await resolveApiKeyForProviderRaw({ provider, cfg });
  return { mode, source };
}

If plugins truly need to call providers directly, require an explicit configuration flag (default off) and strongly document that enabling it grants plugins access to host credentials.

Analyzed PR: #41090 at commit ee96e96

_{Last updated on: 2026-03-09T23:45:44Z}

Greptile Summary

This PR exposes model authentication to context-engine plugins by adding a modelAuth namespace to PluginRuntimeCore / createPluginRuntime, and re-exporting the related helpers and types from the openclaw/plugin-sdk barrel. The change is small, well-scoped, and consistent with the existing runtime architecture.

Key changes:

• runtime.modelAuth is added with getApiKeyForModel and resolveApiKeyForProvider wired directly to the existing src/agents/model-auth.ts implementations.
• requireApiKey and ResolvedProviderAuth are re-exported from the SDK barrel for plugin authors who need the sync helper or the type directly.
• The mock in test-utils is kept in sync with the new interface field.
• A new test verifies reference equality, confirming the functions are not wrapped.

No issues were found. The implementation is clean and correctly follows the established patterns used by the other runtime namespaces (state, tts, stt, etc.).

Confidence Score: 5/5

• This PR is safe to merge — it is a minimal, additive change with no breaking modifications to existing runtime behaviour.
• All five changed files are consistent with one another (type definition, implementation, mock, and test). The new modelAuth property follows the same structural pattern as existing runtime namespaces, functions are wired directly without wrapping, and the test confirms correct reference equality. No existing code paths are modified.
• No files require special attention.

_{Last reviewed commit: dbb966c}

Addressing Aisle Security Finding

Finding: 🟠 High — Plugin runtime exposes raw API keys with no permission gating (CWE-200)

Mitigation applied (commit 33c956a): Wrapped getApiKeyForModel and resolveApiKeyForProvider so plugins cannot pass agentDir or store overrides. Only provider, model, cfg, profileId, and preferredProfile are forwarded to the underlying auth pipeline. This prevents plugins from steering credential lookups outside their own context.

Regarding the broader concern (raw API key exposure): Plugins already have access to runtime.config.loadConfig() which returns the full config including models.providers.*.apiKey. The plugin trust model in OpenClaw treats installed plugins as trusted code — the user explicitly installs them via openclaw plugins install. The modelAuth helpers provide a standard resolution path (config → env → auth profiles) rather than forcing plugins to parse credentials themselves, which would be more error-prone.

A full host-mediated auth layer (Aisle recommendation #1) would be a larger architectural change beyond the scope of this fix. The agentDir restriction addresses the most actionable part of the finding.

Addressing Aisle Follow-up (CWE-285)

Finding: 🟠 High — Plugin SDK exports raw model-auth functions, allowing credential steering via agentDir/store bypass

Good catch. The runtime.modelAuth wrappers stripped unsafe parameters, but the plugin-sdk barrel still re-exported the raw functions — plugins could import them directly and bypass the wrappers.

Fix applied (commit 7c34f43): Removed getApiKeyForModel and resolveApiKeyForProvider from the plugin-sdk barrel export. Plugins must now use runtime.modelAuth which enforces parameter stripping. Only requireApiKey (sync null-check, no agentDir param) and the ResolvedProviderAuth type remain exported.

Rebased onto latest main — CHANGELOG conflict resolved. Branch is stable now, all changes finalized.

@aisle-research-bot review

Fixed CI: oxfmt whitespace issue in CONTRIBUTING.md (inherited from upstream rebase). All changes finalized.

🔒 Aisle Security Analysis

We found 2 potential security issue(s) in this PR:

1. 🔵 Plugin runtime modelAuth types expose unsafe agentDir/store overrides (type-level guard bypass)

Description

PluginRuntimeCore.modelAuth is typed as the raw model-auth helper functions, even though the runtime implementation intentionally strips agentDir and store to prevent credential-store steering.

This creates a security regression risk / defense-in-depth bypass at the type level:

• The raw helper parameter object includes optional agentDir and store.
• By reusing the raw function types in the plugin runtime surface, plugin authors can pass agentDir/store without any TypeScript error.
• Although createPluginRuntime() currently forwards only safe fields, this typing makes it easy for future refactors (e.g., ...params) to accidentally reintroduce credential steering and will not be caught by the type system.

Vulnerable typing (exposes raw signature):

modelAuth: {
  getApiKeyForModel: typeof import("../../agents/model-auth.js").getApiKeyForModel;
  resolveApiKeyForProvider: typeof import("../../agents/model-auth.js").resolveApiKeyForProvider;
};

Raw helper parameters include the unsafe fields:

• resolveApiKeyForProvider(params: { ...; store?: AuthProfileStore; agentDir?: string; })
• getApiKeyForModel(params: { ...; store?: AuthProfileStore; agentDir?: string; })

While this is not an immediate runtime exploit (wrappers currently drop those fields), it undermines the intended security boundary for plugins and increases the chance of a future credential isolation bypass.

Recommendation

Define restricted parameter types for the plugin runtime wrappers and avoid exporting the raw helper function types.

Example (omit unsafe overrides):

import type {
  getApiKeyForModel as getApiKeyForModelRaw,
  resolveApiKeyForProvider as resolveApiKeyForProviderRaw,
} from "../../agents/model-auth.js";

type GetApiKeyForModelParams = Omit<
  Parameters<typeof getApiKeyForModelRaw>[0],
  "agentDir" | "store"
>;

type ResolveApiKeyForProviderParams = Omit<
  Parameters<typeof resolveApiKeyForProviderRaw>[0],
  "agentDir" | "store"
>;

export type PluginRuntimeCore = {
  ​// ...
  modelAuth: {
    getApiKeyForModel: (params: GetApiKeyForModelParams) => ReturnType<typeof getApiKeyForModelRaw>;
    resolveApiKeyForProvider: (
      params: ResolveApiKeyForProviderParams,
    ) => ReturnType<typeof resolveApiKeyForProviderRaw>;
  };
};

Add a type-level/contract test asserting that agentDir and store are rejected for runtime.modelAuth.* calls (so accidental spreading/forwarding is more likely to be caught during review/CI).

2. 🔵 Plugin runtime exposes unrestricted modelAuth API enabling API key exfiltration via profileId/cfg injection

Description

createPluginRuntime() now exposes runtime.modelAuth.getApiKeyForModel() / resolveApiKeyForProvider() to plugin code. These wrappers return raw provider credentials (API keys / OAuth tokens) and forward plugin-controlled parameters (profileId, preferredProfile, cfg) into the host credential-resolution logic.

In src/agents/model-auth.ts, resolveApiKeyForProvider():

• Accepts an arbitrary profileId and, if provided, resolves and returns that profile’s credential without any authorization check or binding to a caller/session identity.
• Falls back to resolving credentials from the global auth profile store (ensureAuthProfileStore(undefined) when agentDir/store aren’t provided) and from process environment variables.
• Accepts a caller-provided cfg which influences credential resolution (provider config, auth ordering, secret-ref resolution defaults). A plugin can supply a crafted config object rather than the host’s active config snapshot.

Because plugins execute as third-party code, this newly exposed API provides a straightforward credential-exfiltration primitive: a plugin can call runtime.modelAuth.resolveApiKeyForProvider({ provider: "openai" }) (or specify profileId) and receive the raw key/token in-process.

Vulnerable code (newly added):

modelAuth: {
  getApiKeyForModel: (params) =>
    getApiKeyForModelRaw({
      model: params.model,
      cfg: params.cfg,
      profileId: params.profileId,
      preferredProfile: params.preferredProfile,
    }),
  resolveApiKeyForProvider: (params) =>
    resolveApiKeyForProviderRaw({
      provider: params.provider,
      cfg: params.cfg,
      profileId: params.profileId,
      preferredProfile: params.preferredProfile,
    }),
},

Impact depends on trust model, but if plugins are not fully trusted, this is a direct bypass of credential isolation (and can be used to exfiltrate user/host API keys and bearer tokens).

Recommendation

If plugins are intended to be untrusted or semi-trusted, do not expose raw credential material to them.

Recommended fixes (choose one depending on intended trust boundary):

1. Remove/replace the API: expose a higher-level capability that performs provider calls on behalf of the plugin (returning only the requested model result), not the API key.

2. Enforce authorization/scoping:

   • Do not accept cfg from plugin callers; load the host’s active config snapshot internally.
   • Do not allow arbitrary profileId/preferredProfile from plugin callers; instead:
     • derive the profile selection from host policy (e.g., per-plugin allowlist of providers/profiles), and/or
     • only allow selecting from a set of profiles explicitly granted to that plugin.

Example: ignore caller-controlled cfg/profileId and restrict provider selection:

resolveApiKeyForProvider: async ({ provider }) => {
  if (!ALLOWED_PROVIDERS_FOR_PLUGIN.has(provider)) {
    throw new Error("Provider not allowed");
  }
  const cfg = loadConfig(); // or a runtime snapshot
  return resolveApiKeyForProviderRaw({ provider, cfg });
}

3. If the goal is only to ensure a provider is configured, expose a boolean/metadata API (e.g., hasAuthForProvider) rather than returning credentials.

Analyzed PR: #41090 at commit 81ac956

_{Last updated on: 2026-03-09T19:01:11Z}

Addressing Aisle CWE-862 (profile steering)

Stripped profileId and preferredProfile from plugin modelAuth wrappers. Plugins now only specify provider/model — the core auth pipeline selects the credential. TypeScript types are also narrowed so these params cannot be passed at compile time.

Remaining Aisle concern (raw API key exposure): This is inherent to the plugin trust model — plugins are explicitly installed by the user (openclaw plugins install) and already have access to runtime.config.loadConfig() which returns full config including API keys. A host-mediated auth layer would be a larger architectural change beyond this fix's scope.

Note on Aisle 🟠 High: There's a fundamental trade-off here — the whole point of this PR is to let context-engine plugins (like lossless-claw) call LLM APIs, which requires API keys. If we don't expose keys, #40902 stays broken. We've hardened the surface as much as possible (stripped agentDir, store, profileId, preferredProfile), but the raw key exposure is inherent to the feature.

Merged via squash.

• Prepared head SHA: ee96e96
• Merge commit: 4790e40

Thanks @xinhuagu!