GenAI Applications for AI Workspace

[Arshardh]

GenAI Applications

What is the problem that we are trying to solve?

• In the current AI workspace, access to LLM providers and proxies is controlled at the API key level, which ties usage to individual credentials rather than to the applications actually consuming AI capabilities.
  This creates a gap where:

  • AI usage cannot be attributed to specific applications or teams
  • There is no unified view of how different applications consume models, tokens, or cost
  • Governance is fragmented, making it difficult to enforce limits, policies, or quotas at an application level

  As a result, the platform lacks application-level visibility, control, and accountability for Generative AI usage.

Who are we solving the problem for?

• Gen AI Application developers.
• Platform Administrators

Why should it be solved?

• Application developers and Platform Administrators would want to get an idea on how much resources have been consumed by Generative AI related applications.
• Platform Administrators will need to enforce usage caps on Applications that consume the particular LLM Provider.

Use Cases

AI Workspace use case

• Gen AI app developers need to map their existing API keys generated, to an Application.
• Gen AI app developers need to view existing mappings for API keys and remove unwanted mappings that exists.

Analytics Dashboard use case

• Gen AI app developers need to be able to view how much resources have been consumed by their particular application.
• Platform administrators need to keep track of resource utilization by each app so that they can enforce necessary controls as and when required.

Proposed Solution

User Flow

1. GenAI App Developers generate API keys to access LLM Providers or proxies.
   1. Go to LLM Provider/Proxy -> Overview page to generate API keys to access the entity.

2. GenAI App Developers Create a new application to represent the GenAI application they are working on.

3. Gen AI App developers attach their api key generated initially to their application created

4. Gen AI App developers view/remove application keys attached to the particular application

5. When the AI gateway is accessed with this mapped API key, the gateway should identify the application and publish analytics data and enforce controls accordingly.

Implementation

• GenAI App Developers Create a new application to represent the GenAI application they are working on.
  • Implement /applications REST API in platform-api to store these applications
  • Applications are binding to a project level
  • GET/POST/PUT/DELETE /applications?organizationId=1234

{
  "id": "app-handle",
  "name": "Docs Assistant App",
  "projectId": "019d047d-bd5d-76ed-852b-0aca99d41fac",
  "type": "genai",
  "description": "Doc Assistant Application developed to serve users going through our documentation",
  "createdBy": "david"
}

	Database table  

CREATE TABLE IF NOT EXISTS applications (
    uuid VARCHAR(40) PRIMARY KEY,
    handle VARCHAR(255) NOT NULL,
    project_uuid VARCHAR(40),
    organization_uuid VARCHAR(40) NOT NULL,
    created_by VARCHAR(255),
    name VARCHAR(255) NOT NULL,
    description VARCHAR(1023),
    type VARCHAR(50) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (project_uuid) REFERENCES projects(uuid) ON DELETE CASCADE,
    FOREIGN KEY (organization_uuid) REFERENCES organizations(uuid) ON DELETE CASCADE,
    UNIQUE(project_uuid, organization_uuid, name),
    UNIQUE(handle, organization_uuid)
);

• Gen AI App developers attach their api key generated initially to their application created
  • Implement /applications/{appId}/api-keys REST API in platform-api to store these key mappings
  • A particular developer can only add their own keys they generated
  • POST /applications/{appId}/api-keys?organizationId=1234

{
  "apiKeys": [
    {
      "keyId": "production-key-1",
      "associatedEntity": {
        "id": "mistral-provider"
      }
    }
  ]
}

	Database Table

CREATE TABLE IF NOT EXISTS application_api_keys (
    application_uuid VARCHAR(40) NOT NULL,
    api_key_id VARCHAR(40) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (application_uuid, api_key_id),
    FOREIGN KEY (application_uuid) REFERENCES applications(uuid) ON DELETE CASCADE,
    FOREIGN KEY (api_key_id) REFERENCES api_keys(uuid) ON DELETE CASCADE
);

• Gen AI App developers view application keys attached to the particular application
  • Implement /applications/{appId}/api-keys REST API in platform-api to view/ remove these key mappings
  • GET /applications/{appId}/api-keys?organizationId=1234

{
  "count": 1,
  "list": [
    {
      "keyId": "production-key-1",
      "associatedEntity": {
        "id": "mistral-provider",
        "kind": "LlmProvider"
      },
      "status": "active",
      "userId": "david",
      "createdAt": "2026-03-05T18:04:16.685422+05:30",
      "updatedAt": "2026-03-05T18:04:16.685422+05:30",
      "expiresAt": "2026-12-31T23:59:59Z"
    },  ],
  "pagination": {
    "total": 1,
    "offset": 0,
    "limit": 10
  }
}

• DELETE /applications/{appId}/api-keys/{keyId}/?entityID=mistral-provider

• A developer or admin can remove a mapping created by another developer since the application is shared within the project.

• When the AI gateway is accessed with this mapped API key, the gateway should identify the application and publish analytics data and enforce controls accordingly.

  • Store application ID to key ID mappings along with Application name in the Gateway level, and use this information to publish application information in analytics events and for consumer based rate limiting.

  • Alternative approach: Store and update these mappings in the Moesif end and show analytics dashboards depending on these mappings.

    Introduce new Application update event to update the gateway with new application to API Key mappings.

type ApplicationKeyMappingPayload struct {
	ApiKeyUuid string `json:"apiKeyUuid"`
}

// ApplicationUpdatedEventPayload represents the payload for application mapping updates.
type ApplicationUpdatedEventPayload struct {
	ApplicationId   string                         `json:"applicationId"`
	ApplicationUuid string                         `json:"applicationUuid"`
	ApplicationName string                         `json:"applicationName"`
	ApplicationType string                         `json:"applicationType"`
	Mappings        []ApplicationKeyMappingPayload `json:"mappings"`
}

// ApplicationUpdatedEvent represents the complete application updated event.
type ApplicationUpdatedEvent struct {
	Type          string                         `json:"type"`
	Payload       ApplicationUpdatedEventPayload `json:"payload"`
	Timestamp     string                         `json:"timestamp"`
	CorrelationID string                         `json:"correlationId"`
	UserId        string                         `json:"userId"`
}

Add tables in the gateway end to store these mappings along with the application metadata

CREATE TABLE IF NOT EXISTS applications (
    application_uuid TEXT PRIMARY KEY,
    application_id TEXT NOT NULL,
    application_name TEXT NOT NULL,
    application_type TEXT NOT NULL,
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX IF NOT EXISTS idx_applications_application_id ON applications(application_id);

-- Application to API key mappings
CREATE TABLE IF NOT EXISTS application_api_keys (
    application_uuid TEXT NOT NULL,
    api_key_id TEXT NOT NULL,
    gateway_id TEXT NOT NULL,
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (application_uuid, api_key_id, gateway_id),
    FOREIGN KEY (application_uuid) REFERENCES applications(application_uuid) ON DELETE CASCADE,
    FOREIGN KEY (api_key_id, gateway_id) REFERENCES api_keys(uuid, gateway_id) ON DELETE CASCADE
);