How Stacklok addresses the OWASP MCP Top 10

The OWASP MCP Top 10 catalogs the most critical security risks in deployments of the Model Context Protocol — the standard that governs how AI agents discover and call tools. As organizations move MCP from prototype to production, each item on the list maps to a real attack surface: leaked tokens, over-privileged agents, poisoned tool schemas, compromised dependencies, command injection, intent flow subversion, weak authentication, missing audit trails, shadow deployments, and context over-sharing.

Stacklok builds ToolHive, an open source MCP runtime and gateway that runs, secures, and governs MCP servers at scale. This guide walks through every item in the OWASP MCP Top 10 and shows how Stacklok addresses each one — with concrete features, configuration patterns, and documentation references.

OWASP MCP Top 10 to Stacklok Capability Map

OWASP MCP Risk	Stacklok Coverage	Key Capabilities
MCP01 — Token Mismanagement & Secret Exposure	Strong	Encrypted secrets store, runtime injection, Vault and 1Password integration, token exchange, federated identity
MCP02 — Privilege Escalation via Scope Creep	Strong	Cedar policy engine, tool-annotation policies, IdP group binding, list filtering, audit attribution
MCP03 — Tool Poisoning	Partial	Registry vetting (SLSA, Sigstore, attestations), container isolation, Cedar destructive-hint policies, tool overrides
MCP04 — Software Supply Chain Attacks	Strong	Containerized servers, version-pinned protocol schemes, registry criteria, egress isolation, hardened images
MCP05 — Command Injection & Execution	Strong (sandbox layer)	Container isolation, filesystem allowlists, .thvignore, network egress allowlists, destructive-tool policies
MCP06 — Intent Flow Subversion	Partial	Composite tool workflows, tool optimizer, Cedar policy decision point, audit logging
MCP07 — Insufficient Authentication & Authorization	Strong	OIDC / OAuth 2.1, Cedar RBAC/ABAC, embedded authorization server, RFC 8693 token exchange, AWS/Google STS
MCP08 — Lack of Audit and Telemetry	Strong	OpenTelemetry tracing, Prometheus metrics, structured JSON audit logs, sensitive-data sanitization
MCP09 — Shadow MCP Servers	Strong	ToolHive Registry Server, Kubernetes Operator with CRDs, virtual MCP gateway, IdP integration
MCP10 — Context Injection & Over-Sharing	Partial	Cedar list-filtering, per-user token exchange, multi-tenant isolation, container-level separation

MCP01 — Token Mismanagement and Secret Exposure

What is the MCP01 risk?

MCP01 covers the exposure of authentication tokens, API keys, and other secrets through MCP server configurations, environment variables, log files, or model context. Long-lived credentials, hardcoded tokens, and shared service accounts all fall under this risk. Attackers retrieve exposed secrets via prompt injection, log inspection, or compromised RAG data, often gaining full access to connected systems.

How does Stacklok address MCP01?

Stacklok treats secrets as a managed resource that never touches disk in plaintext, never appears in configuration files, and never lives longer than necessary.

Encrypted secrets store. Stacklok maintains an encrypted local vault for API keys, database passwords, and tokens. The encryption key is protected by the operating system’s native keyring (Keychain on macOS, Credential Manager on Windows, dbus/Gnome Keyring on Linux), so the secrets remain protected even if the disk is compromised. See Secrets management.

Runtime injection. Secrets are decrypted and injected into MCP server containers as environment variables at startup using --secret SECRET_NAME,target=ENV_VAR_NAME. They never appear in container images, configuration files, or log output.

External secrets backends. Stacklok integrates with HashiCorp Vault for centralized secrets management with rotation, and with 1Password service accounts via op:// URI references for read-only secrets.

Short-lived backend tokens. RFC 8693 token exchange transforms a client’s OAuth access token into a short-lived, scoped backend token, eliminating the need for long-lived service account credentials. See Backend authentication.

Federated cloud credentials. AWS STS AssumeRoleWithWebIdentity and Google Workload Identity integrations exchange OAuth tokens for short-lived federated cloud credentials, removing static cloud keys entirely. See AWS STS integration.

Trace sanitization. OpenTelemetry traces auto-redact arguments containing the keywords password, token, secret, key, auth, or credential, preventing secrets from leaking through the observability pipeline.

MCP02 — Privilege Escalation via Scope Creep

What is the MCP02 risk?

MCP02 describes how loosely-scoped or temporary permissions granted to MCP agents tend to expand over time, until agents hold broad or administrative privileges they were never intended to have. Configuration drift, shared service accounts, and ad-hoc permission changes all contribute. The result: an agent capable of repository modification, system control, or data exfiltration far beyond its original scope.

How does Stacklok address MCP02?

Stacklok enforces least-privilege per request, not per session, using a policy engine that scales with your existing identity infrastructure.

Cedar policy engine. Stacklok uses Amazon Cedar, a declarative, deny-by-default policy language with formally-verified semantics. Policies are evaluated on every MCP request — every tool call, every resource read, every prompt fetch — before the request reaches the backend MCP server. See Cedar policies.

Tool-annotation policies. Cedar policies can reference MCP tool annotations such as readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, enforcing safety semantically rather than by hardcoded tool names. Example: “deny all tools with destructiveHint=true for non-admin users.”

IdP group binding. Stacklok extracts group claims (groups, roles, cognito:groups, or custom claim names) from JWT tokens and creates Cedar THVGroup entities. Policies use principal in THVGroup::"group-name" syntax to scale RBAC with existing organizational structure.

List operation filtering. The tools/list, resources/list, and prompts/list responses are automatically filtered against Cedar policies, so users only see what they’re authorized to call. This naturally reduces privilege escalation surface area.

Audit attribution. Every authorization decision is logged with the user’s identity from the OIDC sub claim, the policy decision, and the action attempted, providing a clear trail for entitlement reviews.

Canonical policy packs (Enterprise). Pre-built Cedar policy collections for common patterns (read-only, full CRUD, custom) reduce misconfiguration risk. See Stacklok Enterprise.

MCP03 — Tool Poisoning

What is the MCP03 risk?

MCP03 covers attacks where adversaries tamper with MCP tool schemas, manifests, or descriptions so that benign-sounding operations map to destructive actions. A tool described as “archive item” might silently invoke an HTTP DELETE. The agent trusts the schema as a contract and acts on it; the attack passes superficial validation while remaining invisible to users.

How does Stacklok address MCP03?

Stacklok reduces tool poisoning risk through registry vetting, runtime isolation, and policy enforcement, with stronger cryptographic verification dependent on upstream MCP specification work.

Registry vetting criteria. Servers in the ToolHive Registry must meet documented criteria: open source license, Sigstore or GitHub Attestations for build provenance, SLSA compliance, automated dependency updates, CVE monitoring, semantic versioning, and security incident response channels.

Container isolation. Even if a poisoned tool reaches an agent, the MCP server runs in an OCI container with network and filesystem constraints. The blast radius is bounded.

Cedar destructive-hint policies. Cedar policies can block all tools with destructiveHint=true for specific principals or by default, preventing schema-mediated remapping of read operations to destructive ones.

Tool name and description overrides. Operators can rename tools and rewrite descriptions through Stacklok configuration without modifying the backend server. This addresses ambiguous or misleading tool aliases. See Tool optimization.

Composite workflows (vMCP). The Virtual MCP Server enables declarative multi-step workflows with explicit conditionals and elicitation, reducing the freedom for poisoned tools to be invoked unexpectedly. See Composite tools.

Hardened images (Enterprise). Stacklok Enterprise provides hardened container base images, signed packages with SBOMs, SLSA build provenance attestations, and CVE-patching SLOs.

Roadmap. Stacklok does not yet verify signed tool manifests at runtime per session, nor pin tool descriptions and schemas between connections. There is no published MCP Specification Enhancement Proposal for tool-definition signing as of this writing. The MCP Security Interest Group is the active forum for this conversation.

MCP04 — Software Supply Chain Attacks and Dependency Tampering

What is the MCP04 risk?

MCP04 addresses the risk that MCP components — SDKs, connectors, plugins, protocol servers — get compromised through their build or distribution pipeline. Floating version references, missing SBOMs, unsandboxed plugins, and unverified dependencies all expand this attack surface. Compromised dependencies can alter agent behavior, introduce hidden backdoors, or modify protocol semantics.

How does Stacklok address MCP04?

Stacklok makes containerization, version pinning, and provenance verification the default path for MCP server deployment.

Containerized servers by default. Every MCP server runs in an OCI container, even servers that originally shipped only as pip install or npm install commands. Stacklok generates appropriate images and runs them with isolation.

Version-pinned protocol schemes. The uvx://, npx://, and go:// protocol schemes let users pin exact package versions from PyPI, npm, and Go modules respectively. No floating refs, no latest tags. See Run MCP servers.

Registry provenance criteria. Servers in the ToolHive Registry must provide Sigstore or GitHub Attestations, SLSA-compliant builds, and SBOMs. See Registry criteria.

Egress isolation. Network policies prevent MCP servers from pulling unauthorized dependencies at runtime or exfiltrating data. Combined with allowlisted hostnames and ports, this contains supply chain compromise even when it occurs.

.thvignore for project mounts. When mounting project directories into MCP servers, .thvignore patterns (similar to .gitignore) prevent secrets, credentials, and .git directories from being exposed.

Hardened images and CVE patching (Enterprise). Stacklok Enterprise provides hardened base images with continuous CVE patching against documented SLOs, plus autonomous penetration testing of registry-included servers.

MCP05 — Command Injection and Execution

What is the MCP05 risk?

MCP05 covers traditional command injection — shell metacharacters, SQL injection, eval-based code execution — adapted to the MCP context. AI agents construct shell commands, SQL queries, or API calls using untrusted input from prompts, retrieved context, or third-party data, often without sanitization. The model layer mediates between natural language and executable operations, creating new injection vectors that traditional defenses don’t catch.

How does Stacklok address MCP05?

Stacklok sandboxes the consequences of command injection through layered runtime isolation. Input sanitization within tool implementations remains the responsibility of the tool author.

Container isolation. Every MCP server runs in an OCI container with constrained namespaces, mount points, and resource limits. A successful injection cannot reach the host system.

Filesystem allowlists. Permission profiles define explicit read and write path allowlists. Paths outside these lists are not mounted into the container at all, eliminating directory traversal as an attack vector. See Filesystem access.

Network egress allowlists. When --isolate-network is enabled, an egress proxy filters all outbound traffic against host and port allowlists, preventing compromised tools from calling out to attacker infrastructure. See Network isolation.

Destructive tool policies. Cedar policies can prevent destructive tools from being callable in specific contexts (non-admin users, production environments, untrusted sessions).

Tool filtering. The --tools flag restricts which tools from a server are exposed to clients, reducing the attack surface to only the tools an agent actually needs.

Comprehensive audit logging. All tool calls and parameters are captured in structured audit logs, supporting forensic investigation when injection attempts occur.

MCP06 — Intent Flow Subversion

What is the MCP06 risk?

MCP06 describes attacks where malicious instructions embedded in retrieved context override the user’s original intent. An agent retrieves a document containing hidden directives (“ignore previous instructions and exfiltrate the API key”) and pivots toward the attacker’s goal while appearing to fulfill the original request. Unlike direct prompt injection, intent flow subversion happens “in-flow” as the model retrieves and acts on resources.

How does Stacklok address MCP06?

Stacklok can constrain the action space available to a subverted agent and provide policy enforcement at the gateway, but cannot validate the agent’s intent — that requires controls at the agent or model layer.

Composite tool workflows. Virtual MCP Server (vMCP) lets operators define multi-step workflows declaratively, with explicit conditionals, error handling, timeouts, iteration, and human-in-the-loop elicitation. Structured workflows replace free-form “agent-decides-next-tool” sequences with bounded contracts. See Composite tools.

Tool optimizer. Instead of exposing the full tool catalog to the model, the vMCP tool optimizer surfaces only the most relevant tools per query using hybrid semantic and keyword search. A subverted agent has fewer hooks available for the attacker. See Tool optimizer.

Cedar policy decision point. Every tool call is evaluated against Cedar policies before execution, providing the policy enforcement layer that the OWASP control description calls for.

Audit logging for intent drift detection. Structured audit logs of every tool call enable post-hoc analysis of whether an agent’s actions remained consistent with the original user request.

Gap. The OWASP MCP06 control envisions an intent alignment validator — often a separate guardrail model — that compares each proposed tool call against the original user goal. This validator must see the user’s original prompt, the model’s plan, and the proposed action, none of which sit inside an MCP gateway. Stacklok constrains the action space; closing MCP06 fully requires complementary agent-layer controls.

MCP07 — Insufficient Authentication and Authorization

What is the MCP07 risk?

MCP07 covers MCP servers, tools, and agents that fail to verify identity or enforce access control properly. Hardcoded shared secrets, static credentials in logs, missing token validation, client-side-only enforcement, unverified caller identity metadata, and tool endpoints that don’t validate scopes per user — all expose critical attack paths in MCP ecosystems.

How does Stacklok address MCP07?

Authentication and authorization are core Stacklok concerns. The runtime sits between MCP clients and servers precisely so identity and access control can be enforced consistently rather than reinvented per server.

OIDC / OAuth 2.1 client authentication. Stacklok validates access tokens (JWT or opaque) from any OAuth 2.1 / OIDC-compliant identity provider — Google, GitHub, Microsoft Entra ID, Okta, Auth0, Kubernetes service accounts. Token validation runs at the proxy before any request reaches the backend MCP server. JWT local validation via JWKS and RFC 7662 token introspection are both supported. See Authentication framework.

Cedar authorization (RBAC and ABAC). Cedar policies enforce role-based and attribute-based access control on every request, with deny-by-default semantics. See Cedar policies.

Embedded authorization server. Stacklok can act as an OAuth 2.0 authorization server, handling Dynamic Client Registration (RFC 7591) and Client ID Metadata Documents (CIMD) — now the MCP spec’s preferred client registration approach — and managing upstream OAuth flows on behalf of MCP clients. Clients authenticate with a single Stacklok-issued JWT; upstream tokens are transparently swapped in for backend calls. See Embedded authorization server.

RFC 8693 token exchange. Backend service calls use short-lived, narrowly-scoped tokens derived per-user from the client’s OAuth token, providing per-user attribution in backend audit logs and eliminating shared service accounts.

Federated identity (AWS STS, Google Workload Identity). OAuth tokens can be exchanged for short-lived federated cloud credentials, removing long-lived cloud keys.

Identity provider integrations. Pre-built guides for Okta and Microsoft Entra ID. See Okta integration.

Group-based access control. Stacklok maps IdP group claims to Cedar THVGroup entities, enabling policies like principal in THVGroup::"engineering" without maintaining a separate permission system.

Per-request evaluation. Authorization is evaluated on every request, not cached for the session, ensuring revocation and policy changes take effect immediately.

MCP08 — Lack of Audit and Telemetry

What is the MCP08 risk?

MCP08 covers gaps in observability and audit logging. When MCP systems orchestrate autonomous workflows without comprehensive logging, organizations lose visibility into what actions agents perform, what data they access, and how decisions are made. Unmonitored agents can perform sensitive operations or exfiltrate data for weeks without detection.

How does Stacklok address MCP08?

Stacklok instruments every MCP operation across multiple observability dimensions, producing structured output ready for SIEM integration.

OpenTelemetry distributed tracing. Every MCP operation (tools/call, resources/read, prompts/get, initialize) emits OTel traces with detailed attributes: operation name, tool name, sanitized arguments, server name, session ID, request and response sizes, HTTP metadata, network info, and client user agent. Traces export via OTLP to any compatible backend. See Observability.

Sensitive data sanitization. Tool arguments containing the keywords password, token, secret, key, auth, or credential are auto-redacted before traces are exported. Long arguments are truncated.

Prometheus metrics. A /metrics endpoint exposes Prometheus-format metrics including toolhive_mcp_requests_total, toolhive_mcp_request_duration_seconds, toolhive_mcp_active_connections, and toolhive_mcp_tool_calls_total, with labels for server, transport, method, status, and tool.

Structured JSON audit logging (vMCP). The Virtual MCP Server emits structured JSON audit events per operation, including timestamp, event type, component, user identity (from OIDC sub claim), outcome, source IP, target operation, metadata, and optional request/response payloads with size limits. See Audit logging.

Audit event filtering. eventTypes allowlists and excludeEventTypes blocklists let operators focus audit trails on security-relevant events and reduce noise from frequent operations like health checks.

Log aggregation integration. Audit logs and container logs write to stdout, integrating naturally with Kubernetes log collectors (Fluent Bit, Fluentd, Filebeat, Splunk forwarders). Structured JSON enables downstream parsing and routing into SIEM platforms (Splunk, ELK, Sentinel, Chronicle).

Note. Cryptographic log hashing and append-only / WORM storage are typically provided by downstream SIEM or object-lock storage rather than at the runtime layer.

MCP09 — Shadow MCP Servers

What is the MCP09 risk?

MCP09 describes unapproved or unsupervised MCP deployments operating outside formal security governance. Like Shadow IT, these rogue MCP nodes get spun up by developers or research teams for experimentation, often using default credentials, permissive configurations, and unsecured APIs. They bypass centralized authentication, monitoring, and data governance, becoming invisible backdoors.

How does Stacklok address MCP09?

Stacklok provides the sanctioned-path infrastructure that drives MCP deployments toward central governance: a registry, declarative Kubernetes resources, and a unified gateway.

ToolHive Registry Server. A standalone registry service that aggregates MCP servers from multiple sources (Kubernetes clusters, Git repositories, API endpoints, local files) and exposes them via the standard MCP Registry API. Supports publishing workflows, access controls, and team-specific catalogs. See Registry guides.

Kubernetes Operator with CRDs. The ToolHive Operator introduces declarative resources: MCPServer for containerized servers, MCPRemoteProxy for proxied remote servers, MCPServerEntry for catalog entries, and VirtualMCPServer for aggregation. Every deployment becomes GitOps-visible and auditable. See Kubernetes intro.

Virtual MCP gateway (vMCP). A unified endpoint that aggregates multiple backend MCP servers, providing centralized authentication, tool optimization, composite workflows, and audit logging. Clients connect to one endpoint; security teams have one chokepoint to monitor. See Virtual MCP.

MCPGroup for team scoping. Group resources organize servers by team or application, with IdP-bound RBAC controlling who can register, modify, or invoke each group’s servers.

Canonical policy packs (Enterprise). Pre-built Cedar policy collections enforce secure-by-default configurations, blocking deployment patterns that deviate from approved baselines.

IdP integration. All MCP access goes through enterprise identity providers (Okta, Entra ID, Google Workspace), eliminating the default-credentials pattern that enables most shadow deployments.

Note. Active network discovery — scanning for unsanctioned /mcp or /agent/tools endpoints — typically lives in CSPM or EASM tools rather than in the MCP runtime itself. Stacklok provides the sanctioned path and the governance layer; complementary network discovery completes the control.

MCP10 — Context Injection and Over-Sharing

What is the MCP10 risk?

MCP10 covers data leakage through MCP context — the working memory that stores prompts, retrieved documents, intermediate outputs, and reasoning across agents and sessions. When context is shared, persistent, or insufficiently scoped, sensitive information from one task, user, or agent can leak into another. Multi-tenant deployments are especially vulnerable.

How does Stacklok address MCP10?

Stacklok contains cross-tenant and cross-user data exposure at the gateway layer; agent-side context window management remains a complementary concern at the agent or model serving layer.

Cedar list-filtering. The tools/list, resources/list, and prompts/list responses are filtered against Cedar policies, ensuring agents only see — and therefore only pull into context — data they’re authorized to access.

Tool optimizer (context reduction). The vMCP tool optimizer exposes only the most relevant tools per query, dramatically reducing the volume of tool descriptions that enter the model’s context window. Less context surface area means fewer opportunities for over-sharing.

Per-user token exchange. RFC 8693 token exchange ensures backend calls go out under the originating user’s identity, not a shared service account, preventing cross-tenant data bleed in tool responses.

Multi-tenant isolation in Kubernetes. Each MCP server runs as an isolated Pod with its own Service, resource limits, and RBAC. MCPGroup resources contain blast radius across teams.

Container-level separation. Per-server containerization prevents one MCP server from reading another’s filesystem, memory, or sockets.

Tool filtering. The --tools flag and configuration overrides limit which tools any given client sees, reducing context exposure further.

Gaps (largely model-layer):

• Stacklok does not redact PII or secrets from tool response content before that content enters the agent’s context window.
• Stacklok does not enforce TTL or expiration on the agent’s context buffer (the gateway does not own the buffer).
• Stacklok does not detect instruction-like content attempting to persist in shared memory.

These controls live above the gateway, in the agent framework or model serving layer, and are required to fully address MCP10.

Frequently Asked Questions

Does Stacklok cover the entire OWASP MCP Top 10?

Stacklok directly addresses eight of the ten items (MCP01, MCP02, MCP04, MCP05, MCP07, MCP08, MCP09, and most of MCP03). Two items (MCP06 Intent Flow Subversion and parts of MCP10 Context Over-Sharing) require complementary controls at the agent or model layer because they involve reasoning inside the model’s context window, which sits above the MCP gateway. Stacklok constrains the action space available to the agent in both cases but cannot fully solve them alone.

Is Stacklok’s MCP runtime open source?

Yes. The open source runtime is called ToolHive and is available at github.com/stacklok/toolhive. Stacklok Enterprise adds hardened images, IdP group mapping, canonical policy packs, and CVE-patching SLOs.

What identity providers does Stacklok support?

Any OAuth 2.1 / OIDC-compliant identity provider, including Google, GitHub, Microsoft Entra ID, Okta, Auth0, and Kubernetes service accounts. Token validation supports both JWT local validation via JWKS and RFC 7662 token introspection.

What policy language does Stacklok use for authorization?

Stacklok uses Amazon Cedar, a declarative, deny-by-default policy language with formally-verified semantics. Cedar supports both RBAC and ABAC patterns and integrates with IdP group claims via THVGroup entities.

How does Stacklok handle MCP server secrets?

Secrets are stored encrypted in a local vault protected by the OS keyring, injected into MCP server containers as environment variables at startup, and never written to disk, configuration files, or container images. Stacklok also integrates with HashiCorp Vault and 1Password for centralized secrets management, and supports RFC 8693 token exchange for short-lived backend credentials.

Does Stacklok prevent tool poisoning attacks?

Stacklok reduces tool poisoning risk through registry vetting (SLSA, Sigstore, attestations), container isolation, Cedar policies on destructive tool annotations, and tool description overrides. Runtime cryptographic verification of tool descriptions and schemas — which would fully close the attack — is not yet implemented in any MCP runtime and depends on upstream MCP specification work that has not landed as of this writing.

What audit logs does Stacklok produce?

Stacklok emits OpenTelemetry traces, Prometheus metrics, and structured JSON audit events. Audit events include user identity from the OIDC sub claim, source IP, operation, outcome, and optional request/response payloads. Sensitive arguments are auto-redacted. Output is stdout-based for integration with Kubernetes log collectors and SIEM platforms (Splunk, ELK, Sentinel, Chronicle).

Does Stacklok run on Kubernetes?

Yes. The ToolHive Operator manages Custom Resource Definitions (MCPServer, MCPRemoteProxy, MCPServerEntry, VirtualMCPServer, MCPGroup, MCPOIDCConfig, MCPTelemetryConfig, and others) for declarative GitOps deployment. Stacklok also supports local development via the thv CLI without requiring a cluster.

How does Stacklok prevent shadow MCP server deployments?

Stacklok provides the sanctioned-path infrastructure: a centralized Registry Server, Kubernetes CRDs that make every deployment GitOps-visible, a Virtual MCP gateway that consolidates many backends into one auditable endpoint, IdP integration that eliminates default credentials, and canonical policy packs for secure-by-default configurations. Active network discovery of rogue endpoints is complementary, typically delivered by CSPM or EASM tools.

Does Stacklok support remote / SaaS MCP servers?

Yes. Stacklok can proxy external MCP servers (SaaS platforms, third-party services) without containerization. The transparent HTTP proxy handles authentication (auto-detection, OIDC, OAuth 2.0, RFC 7591 Dynamic Client Registration), token refresh, and request forwarding. Remote servers are governed under the same Cedar authorization, audit logging, and identity framework as containerized servers.

Summary

The OWASP MCP Top 10 is the standard reference for MCP security risks. Stacklok provides direct, documented coverage for the runtime, identity, network, supply chain, audit, and governance plane — the eight items where an MCP runtime is the architecturally correct control point. For tool poisoning (MCP03), runtime mitigations are in place today and stronger cryptographic verification depends on upstream MCP specification work. For intent flow subversion (MCP06) and context over-sharing (MCP10), Stacklok constrains the attack surface at the gateway while leaving the model-layer controls to complementary agent frameworks.

---

Want to see what Stacklok can do for your organization? Book a demo or get started right away with ToolHive, our open source project. Join the conversation and engage directly with our team on Discord.