Roadmap

[l1shen]

Roadmap

Action Run Audit Trail

Status: Delivered by #141.

Action execution is the core runtime boundary for HTTP, MCP, and the Web Console. We should make each action run inspectable after the fact, with enough structured metadata to debug failures, correlate logs, and understand which account and caller were involved.

This is not meant to become a full observability platform yet. The short-term goal is to make action runs traceable, searchable, and safe to inspect without storing raw secrets or full provider payloads by default.

The runtime uses executionId as the stable run and correlation identifier. It does not currently generate a separate traceId.

Tasks

• Extend RunLog with structured audit metadata.
• Add GET /api/runs/:id.
• Add filters to GET /api/runs.
• Propagate executionId through HTTP and MCP responses.
• Include executionId in server logs.
• Keep stored input/output summaries redacted by default.
• Show run audit context and expandable output in the Console.

The Console keeps run inspection inline in the history table. A dedicated per-run detail page is not planned unless future workflows require deep links or substantially richer execution data.

Non-goals

• Metrics dashboard
• OpenTelemetry
• External log sinks
• Raw request/response persistence
• Compliance reporting

Runtime Governance

Status: Delivered by #156.

Move runtime execution policy from static environment configuration toward inspectable, runtime-managed controls.

OpenConnector already supports local allow/block policy for actions and provider proxies. The next step is to make these controls visible, testable, and eventually manageable from the runtime instead of being hidden behind deployment-time environment variables only.

Tasks

• Expose current action/proxy policy through the admin API.
• Show policy state in the Console.
• Add policy evaluation metadata to action guides and run records.
• Support persisted runtime policy configuration.
• Add token-scoped action allow/block rules.
• Add tests for action, proxy, and token-scoped policy decisions.

Non-goals

• Full RBAC
• Multi-tenant team permissions
• Organization/user management
• Approval workflows
• Policy language or custom scripting

[D36u99er]

我在讨论区提交了一份相关架构提案：#74。提案不要求 OpenConnector 内建组织、用户管理或完整角色权限，而是增加通用的外部身份上下文、连接归属和作用域授权，使上层多用户产品可以安全复用同一个运行实例。我们愿意在方向确认后继续贡献设计、数据库迁移、实现和测试。

[tmp-reg]

Hesitant to integrate custom providers, since action allow/forbid rules are globally scoped — a single key can execute actions across all providers, which is extremely risky

[l1shen]

@tmp-reg Thanks — this was a valid concern when you posted it. PR #156 has since added per-token action policies. A runtime token can now be restricted to a provider namespace such as custom_provider.*, or to specific action IDs. Token allowlists intersect with deployment and runtime policies, and Block rules always take precedence, so a scoped token cannot call actions from other providers.

For third-party integrations, use a scoped runtime token rather than sharing the admin token or the static runtime token. An empty token allowlist still means no additional restriction. Token policies currently scope actions; provider proxy requests remain governed by deployment and runtime policy rather than per-token rules, and tokens are not currently bound to individual connections.