Skip to Content
DocsSDKsSecurity

Security Considerations

The @ithena-one/mcp-governance SDK provides a framework for adding security and governance controls, but the overall security of your MCP server heavily depends on how you implement and configure its components. Please review these points carefully.

1. Authentication (IdentityResolver)

  • SDK Role: Facilitates identity use, does not perform authentication.
  • Your Responsibility: Implement IdentityResolver to securely verify credentials (JWT, API keys, etc.) from the transport layer.
  • Common Pitfalls:
    🚫

    NEVER trust unvalidated headers like X-User-ID in production. Always validate tokens/keys against a trusted source.

    • Ensure robust error handling to prevent info leakage.
    • Protect the communication channel (TLS/HTTPS/WSS).
  • Recommendations: Use standard mechanisms (OAuth 2.0/OIDC token validation, SAML) or an authenticating API Gateway.

2. Authorization (RoleStore, PermissionStore, derivePermission)

  • Least Privilege: Grant only minimum necessary access.
  • Implementation Security: Securely fetch roles/permissions and protect underlying data stores.
  • Permission Granularity: Review defaultDerivePermission. Implement custom logic for more specific permissions if needed (e.g., resource:read:user_data/{userId}). Validate parameters used in derivation.
  • Complexity: Consider policy engines (e.g., OPA) for complex rules, integrated via PermissionStore.

3. Credential Management (CredentialResolver)

  • 🚫

    NEVER Hardcode Secrets in code or config.

  • Secure Storage: CredentialResolver must retrieve secrets from a managed secrets store (Vault, AWS/Azure/GCP Secret Manager).
  • Least Privilege: Grant the server process minimal permissions to access needed secrets.
  • Rotation: Implement regular secret rotation.
  • Contextual Fetching: Fetch secrets based on operation/identity needs.

4. Auditing and Logging (AuditLogStore, Logger, sanitizeForAudit)

🚫

The most significant risk is logging sensitive data. The defaultSanitizeForAudit provides basic masking but is insufficient for production. It may miss sensitive data specific to your app (PII, financial, proprietary info) or incorrectly mask non-sensitive data.

You MUST thoroughly review defaultSanitizeForAudit and implement a custom function tailored to your specific data structures and sensitivity requirements. Test rigorously.

  • Audit Log Storage: Secure the storage location, apply access controls, and set retention policies.
  • Logging Sensitivity: Avoid logging sensitive payloads unless necessary and properly sanitized/masked. Use structured context wisely.

5. Input Validation

  • Handler Schemas: Always use Zod schemas (or equivalent) when registering handlers via GovernedServer for basic structure/type validation.
  • Governance Component Inputs: Validate inputs within your custom components (e.g., params in derivePermission). Do not implicitly trust request data.

6. Error Handling

  • Avoid Leaking Information: Catch errors gracefully. Do not leak internal details/stack traces in client-facing error responses. Map to generic JSON-RPC errors.
  • Monitor Errors: Monitor logs for patterns indicating issues or attacks.

7. Dependencies

  • Keep SDKs (@ithena-one/mcp-governance, @modelcontextprotocol/sdk), zod, and other dependencies updated. Use npm audit / yarn audit.

8. Transport Security

  • Secure the underlying MCP transport (TLS for SSE/WebSockets/HTTP) to protect data in transit.

By carefully implementing the governance components and following these security best practices, you can build robust and secure MCP applications using the @ithena-one/mcp-governance SDK.

Last updated on
InterfacesDefaults