Securing AI and API Endpoints

Every endpoint is a door — lock them all

Securing DAB REST and GraphQL endpoints

Authentication providers

DAB supports multiple authentication providers configured in the runtime section:

"runtime": {
  "host": {
    "authentication": {
      "provider": "AzureAD",
      "jwt": {
        "audience": "api://searchwave-dab",
        "issuer": "https://login.microsoftonline.com/TENANT_ID/v2.0"
      }
    }
  }
}

Provider	How It Works	Best For
AzureAD (Entra ID)	Validates JWT tokens from Microsoft Entra ID	Enterprise apps, Microsoft ecosystem
EasyAuth	App Service/Static Web Apps built-in authentication	Managed hosting with built-in auth
Custom JWT	Any identity provider that issues standard JWTs	Third-party IDPs (Auth0, Okta)

Role-based authorization

After authentication, DAB checks what the user’s role is allowed to do. Roles are defined per entity:

"Product": {
  "permissions": [
    {
      "role": "anonymous",
      "actions": [
        {
          "action": "read",
          "fields": {
            "include": ["id", "name", "price", "description"],
            "exclude": ["internalCost", "supplierNotes"]
          }
        }
      ]
    },
    {
      "role": "editor",
      "actions": [
        { "action": "read" },
        { "action": "create" },
        {
          "action": "update",
          "policy": {
            "database": "@item.ownerId eq @claims.userId"
          }
        }
      ]
    },
    {
      "role": "admin",
      "actions": [{ "action": "*" }]
    }
  ]
}

Key concepts:

• anonymous — no authentication required (public endpoints)
• authenticated — any valid token, regardless of role claim
• Custom roles — matched against role claims in the JWT token
• Field-level security — include/exclude specific columns per role
• Database policies — row-level filters using @item (database column) and @claims (token claim)

💡 Exam tip: Anonymous vs Authenticated vs Custom roles

These three tiers are tested frequently:

• anonymous — no token needed. Use for public-facing read-only data (product catalog, public API).
• authenticated — any valid JWT. Use when you need to know the user’s identity but do not care about their specific role.
• Custom roles (e.g., “editor”, “admin”) — matched against claims in the token. Use for fine-grained permissions.

A common exam trap: setting all entities to “authenticated” when some should be “anonymous” (public data) or role-specific (admin operations). Match the permission level to the sensitivity of the data.

CORS configuration

Cross-Origin Resource Sharing controls which frontends can call your API:

"runtime": {
  "host": {
    "cors": {
      "origins": [
        "https://searchwave.com",
        "https://admin.searchwave.com"
      ],
      "allow-credentials": true
    }
  }
}

Never use "origins": ["*"] in production. It allows any website to call your API, which opens the door to cross-site request forgery and data exfiltration.

Securing AI model endpoints

SQL Server 2025 and Azure SQL can call external AI models directly using sp_invoke_external_rest_endpoint and the new AI integration features. These external calls need security too.

Managed identity for model access

Managed identity eliminates secrets entirely. Your SQL database authenticates to the AI service using its Azure identity — no API keys, no connection strings, no passwords to rotate.

-- Azure SQL calling Azure OpenAI with managed identity
-- The database's managed identity needs 'Cognitive Services User' role
-- on the Azure OpenAI resource
DECLARE @response NVARCHAR(MAX);
EXEC sp_invoke_external_rest_endpoint
    @url = 'https://searchwave-ai.openai.azure.com/openai/deployments/gpt-4o/chat/completions?api-version=2024-06-01',
    @method = 'POST',
    @credential = [https://cognitiveservices.azure.com],
    @payload = '{"messages":[{"role":"user","content":"Summarise this product review"}]}',
    @response = @response OUTPUT;

The @credential parameter tells SQL to use the database-scoped credential mapped to the managed identity. No secret appears anywhere in the code.

When you must use API keys

Some external services do not support managed identity. Store keys in Azure Key Vault and reference them through database-scoped credentials:

-- Create credential with key from Key Vault
CREATE DATABASE SCOPED CREDENTIAL [ExternalAIKey]
WITH IDENTITY = 'HTTPEndpointHeaders',
     SECRET = '{"api-key":"RETRIEVED_FROM_KEYVAULT"}';

Authentication methods for external AI model endpoints

Auth Method	Secrets Stored?	Rotation	Best For
Managed Identity	None — Azure handles tokens automatically	Automatic (no action needed)	Azure-to-Azure service calls
API Key in Key Vault	Key Vault stores the secret	Manual rotation (automate with Key Vault rotation policy)	Third-party AI services without Entra support
API Key in code	In source code or config	Manual and risky	NEVER — this is the wrong approach

💡 Scenario: Ingrid secures the insurance AI endpoint at Nordic Shield

Nordic Shield Insurance uses an Azure OpenAI model to classify insurance claims by severity. The model receives claim descriptions — potentially containing personal health information.

Ingrid implements layered security: (1) managed identity from Azure SQL to Azure OpenAI (no API keys), (2) Azure Private Link so traffic never leaves the Azure backbone network, (3) Azure OpenAI content filtering to block prompt injection attempts, and (4) a database policy in DAB ensuring only the claims-processing service role can trigger AI classification.

If the exam describes a scenario with sensitive data going to an AI model, think: managed identity + private networking + content filtering.

Securing MCP endpoints

Model Context Protocol (MCP) endpoints connect AI agents to tools and data sources. They are powerful — and therefore need strong security.

MCP security fundamentals

Layer	What To Secure	How
Transport	Data in transit	HTTPS only, TLS 1.2+
Authentication	Who is calling	OAuth 2.0 tokens, API keys, managed identity
Authorization	What they can do	Scope-based permissions, tool-level access control
Input validation	What they send	Schema validation, input sanitisation, rate limiting
Network	Where calls come from	Private endpoints, IP allowlists, VNet integration

Key practices

• Use HTTPS for all MCP endpoints — never expose MCP over plain HTTP, even in development
• Authenticate every request — MCP servers should validate tokens before executing any tool
• Limit tool exposure — only expose the tools that each client actually needs
• Log all MCP calls — every tool invocation should be logged for audit and debugging
• Rate limit — prevent abuse by limiting requests per client per time window

💡 Exam tip: Managed identity is almost always the answer

When the exam describes a service-to-service authentication scenario in Azure, managed identity is almost always the correct answer. It eliminates secrets, handles token rotation automatically, and follows the principle of least privilege.

The only exceptions: third-party services outside Azure that do not support Entra ID authentication, and scenarios specifically requiring certificate-based authentication.

Putting it all together

Here is the security surface for a typical DAB deployment:

Internet → CORS filter → Authentication provider → Role check → Field filter → Database
                                                                                   ↓
                                                                           AI Model endpoint
                                                                       (managed identity auth)
                                                                                   ↓
                                                                          MCP tool endpoints
                                                                      (OAuth + scope validation)

Each layer reduces the attack surface. Remove any layer and you create a gap:

• No CORS → any website can call your API
• No authentication → anyone can read your data
• No role check → all authenticated users have admin access
• No field filter → internal data leaks to public endpoints

Question

What is the difference between authentication and authorization in DAB?

Click or press Enter to reveal answer

Answer

Authentication verifies WHO the caller is (validating the JWT token). Authorization checks WHAT they are allowed to do (role-based permissions on entities and fields). DAB handles both: the authentication provider validates tokens, then the permission rules determine which actions and fields each role can access.

Click to flip back

Question

What is managed identity and why is it preferred for service-to-service auth?

Click or press Enter to reveal answer

Answer

Managed identity is an Azure feature where a resource (like Azure SQL) gets an automatically managed identity in Entra ID. It can authenticate to other Azure services without any secrets — no passwords, no API keys, no certificates to rotate. Azure handles token issuance and rotation transparently.

Click to flip back

Question

What does a database policy in DAB do?

Click or press Enter to reveal answer

Answer

A database policy adds a row-level filter to an entity based on claims from the user's token. For example, @item.ownerId eq @claims.userId ensures users can only update their own records. It is similar to Row-Level Security but enforced at the API layer rather than the database layer.

Click to flip back

Knowledge Check

Ingrid at Nordic Shield needs to call an Azure OpenAI endpoint from Azure SQL Database to classify insurance claims. The claims contain personal data. Which authentication approach should she use?

AStore the Azure OpenAI API key in a table in the databaseBUse a managed identity assigned to the Azure SQL logical server and grant it the Cognitive Services User role on the Azure OpenAI resourceCHard-code the API key in the sp_invoke_external_rest_endpoint callDCreate a shared access signature (SAS) token for the Azure OpenAI endpoint

Check Answer

Knowledge Check

A developer configures a DAB entity with permissions set to 'authenticated' for all actions. Users report they can see internal pricing fields they should not have access to. What is the best fix?

ARemove the entity from DAB entirelyBAdd field-level exclusions in the permission to hide sensitive fields from non-admin roles, and create separate role-based permissionsCSet CORS to block those users' browsersDAdd a WHERE clause to the database table

Check Answer

🎬 Video coming soon

Next up: Change Detection: CES, CDC, and Change Tracking — react to data changes with streaming, capture, and tracking mechanisms.