Remediator Agent

Autonomous AI agent that works 24/7 to detect and remediate policy violations across your Kubernetes clusters

Overview

The Remediator Agent is an autonomous AI assistant that runs inside your Kubernetes clusters, working 24/7 on behalf of platform engineering teams. Unlike traditional monitoring tools that simply alert on issues, the Remediator Agent actively analyzes problems, generates solutions, and can automatically remediate policy violations—all while integrating seamlessly with your existing GitOps workflows.

Key Features

  • Violation Detection – Monitors for policy violations reported by Kyverno across all clusters
  • Guided Remediation – AI generates secure, policy-compliant fixes with clear explanations
  • Automated Actions – Creates Pull Requests to update resources in Git repositories, enabling GitOps-friendly remediation
  • Multi-Cluster Support – Manage policy compliance across hundreds of clusters through ArgoCD
  • Audit Trail – Complete logging for compliance reporting and troubleshooting

Benefits

  • Automated detection of policy violations across clusters
  • AI-generated fixes with clear explanations
  • Git workflow integration - no backdoor changes
  • Scheduled operation - runs automatically
  • Reduces resolution times from days to minutes
  • Scales governance without adding headcount

Core Concepts

Custom Resources

The Remediator Agent uses three Kubernetes Custom Resources for configuration:

  • Remediator: Main configuration defining what to scan, when to run, and what actions to take
  • LLMConfig: AI provider settings (defaults to Nirmata AI, supports AWS Bedrock and Azure OpenAI)
  • ToolConfig: Integration settings for Git providers (GitHub, GitLab)

Environment Types

How the agent discovers what to scan:

  • Hub Mode: Uses ArgoCD to manage multiple clusters from a central location
  • Local Mode: Scans the same cluster where the agent is installed

Targets

What the agent monitors for violations:

  • Clusters: Specific Kubernetes clusters by name or server URL
  • Applications: ArgoCD applications you want to monitor
  • Namespaces: Specific namespaces within clusters
  • VCS Repositories: Direct Git repository scanning with policy-resource mapping

Actions

What the agent does when it finds violations:

  • Create Pull Request: Opens a PR in your Git repository with the fix
  • Dry Run: Shows what would be changed without making any modifications

Confidence Levels

NirmataAI analyzes each policy violation and assigns a confidence level to its proposed fix:

  • High Confidence: NirmataAI is highly confident in the accuracy and safety of the proposed fix
  • Low Confidence: NirmataAI has identified a potential fix but recommends human review

You can configure actions (creating PRs or issues) to trigger based on these confidence levels, allowing you to control when automated remediation actions are taken.

Policy Violations

Security, compliance, or configuration problems in your Kubernetes resources detected by Kyverno. Examples include missing resource limits, incorrect security settings, or outdated configurations. The agent processes Kyverno ClusterPolicyReports with fail status results.

Schedules & Triggers

When the agent runs:

  • Cron Schedule: Set specific times (like every 6 hours)
  • Manual Trigger: Run on-demand through the Kubernetes API

Getting Started

The Remediator Agent automatically identifies and fixes policy violations in your Kubernetes clusters and Git repositories using AI-powered remediation. This guide will get you up and running quickly.

Prerequisites

Before installing the Remediator Agent, ensure you have:

Required Components

  • Kubernetes Cluster: Running Kubernetes 1.20+
  • Helm: Helm 3.x installed and configured
  • kubectl: Configured to access your cluster
  • ArgoCD (optional): ArgoCD installed (for hub-spoke setups)

Authentication Requirements

  • Nirmata API Token: Your personal NCH token. If you don’t have an account, sign up for a 15-day free trial to get your API token.

Quick Installation

Create Namespace and Secrets

# Create namespace
kubectl create namespace nirmata

# Create Nirmata API token secret
kubectl create secret generic nirmata-api-token \
  --from-literal=api-token=YOUR_NIRMATA_API_TOKEN \
  --namespace nirmata

Install the Remediator Agent

Add and update Helm repo:

helm repo add nirmata https://nirmata.github.io/kyverno-charts
helm repo update nirmata

Install the Helm chart:

helm install remediator nirmata/remediator-agent --devel \
  --namespace nirmata \
  --create-namespace \
  --set nirmata.apiTokenSecret="nirmata-api-token"

Configuration

1. Setup ToolConfig

The ToolConfig defines how the agent connects to your Git provider.

For GitHub using Personal Access Token:

# Create secret
kubectl create secret generic github-pat-token \
  --from-literal=token=GITHUB_PAT_TOKEN \
  --namespace nirmata

# Create ToolConfig
kubectl apply -f - <<EOF
apiVersion: serviceagents.nirmata.io/v1alpha1
kind: ToolConfig
metadata:
  name: toolconfig-sample
  namespace: nirmata
spec:
  type: github
  credentials:
    method: pat
    pat:
      tokenSecretRef:
        name: github-pat-token
        namespace: nirmata
        key: token
  defaults:
    git:
      pullRequests:
        branchPrefix: "remediation-"
        titleTemplate: "[Auto-Remediation] Fix policy violations: "
        commitMessageTemplate: "Auto-fix: Remediate policy violations: "
        customLabels:
          - "auto-remediation"
          - "security"
        systemLabels:
          - "clusterName"
          - "namespace"
EOF

For GitHub using App (Recommended):

You can securely integrate the Remediator Agent with your GitHub repositories using Nirmata’s GitHub App.

Prerequisites:

  1. Install GitHub App in NCH: Follow the GitHub App Integration guide to connect GitHub in Nirmata Control Hub
    • Navigate to Settings → Integrations
    • Click Connect on the GitHub card
    • Authorize Nirmata to access your repositories
  2. Ensure your SERVICE_ACCOUNT_TOKEN or API_TOKEN environment variable is configured in your cluster

Create ToolConfig:

kubectl apply -f - <<EOF
apiVersion: serviceagents.nirmata.io/v1alpha1
kind: ToolConfig
metadata:
  name: toolconfig-sample
  namespace: nirmata
spec:
  type: github
  credentials:
    method: nirmata-app  # Uses GitHub App configured in NCH
  defaults:
    git:
      pullRequests:
        branchPrefix: "remediation-"
        titleTemplate: "[Auto-Remediation] Fix policy violations: "
        commitMessageTemplate: "Auto-fix: Remediate policy violations: "
        customLabels:
          - "auto-remediation"
          - "security"
        systemLabels:
          - "clusterName"
          - "namespace"
EOF

Benefits:

  • âś… No secrets to manage in Kubernetes
  • âś… Centralized credential management through NCH
  • âś… Automatic token refresh and rotation
  • âś… Better audit trail and access control
  • âś… One-time GitHub App installation for all GitOps operations

For GitLab:

# Create secret
kubectl create secret generic gitlab-pat-token \
  --from-literal=token=GITLAB_PAT_TOKEN \
  --namespace=nirmata

# Create ToolConfig
kubectl apply -f - <<EOF
apiVersion: serviceagents.nirmata.io/v1alpha1
kind: ToolConfig
metadata:
  name: toolconfig-sample
  namespace: nirmata
spec:
  type: gitlab
  credentials:
    method: pat
    pat:
      secretRef:
        name: gitlab-pat-token
        namespace: nirmata
        key: token
EOF

Understanding Pull Request Labels:

The ToolConfig supports two types of labels for pull requests:

  • Custom Labels: Static labels that are always added to PRs (e.g., auto-remediation, security, compliance)
  • System Labels: Dynamic labels computed at runtime based on the remediation context:
    • branch: The Git branch being remediated
    • clusterName: The cluster where violations were found
    • appName: The ArgoCD application name (if applicable)
    • namespace: The Kubernetes namespace containing violations

System labels are only applied when the data is available in the remediation context. For example, clusterName will only be applied in ArgoHub mode and Local Cluster mode.

Example with all label types:

defaults:
  git:
    pullRequests:
      branchPrefix: "fix/"
      titleTemplate: "[Auto-Fix] {{.PolicyName}}"
      commitMessageTemplate: "Remediate: {{.PolicyName}} violations"
      customLabels:
        - "automated"
        - "kyverno-policy"
        - "needs-review"
      systemLabels:
        - "clusterName"
        - "namespace"
        - "appName"

2. Setup LLMConfig

Using Nirmata AI (Default & Recommended):

The Helm chart automatically creates the LLMConfig when you provide the nirmata-api-token secret. No additional configuration needed!

If you need to create it manually:

kubectl apply -f - <<EOF
apiVersion: serviceagents.nirmata.io/v1alpha1
kind: LLMConfig
metadata:
  name: remediator-agent-llm
  namespace: nirmata
spec:
  type: nirmataAI
  nirmataAI:
    endpoint: https://nirmata.io
    model: ""  # Optional: specify a model, otherwise uses default
    apiKeySecretRef:
      name: nirmata-api-token
      key: api-token
      namespace: nirmata
EOF

Using AWS Bedrock (Alternative):

For EKS clusters with Pod Identity Agent:

# Create IAM role and policy (see full AWS setup below)
# Then create LLMConfig
kubectl apply -f - <<EOF
apiVersion: serviceagents.nirmata.io/v1alpha1
kind: LLMConfig
metadata:
  name: remediator-agent-llm
  namespace: nirmata
spec:
  type: bedrock
  bedrock:
    model: MODEL_ARN_OR_INFERENCE_ARN
    region: AWS_REGION
EOF
Full AWS Bedrock Setup Instructions
# Create IAM role
aws iam create-role \
  --role-name remediator-agent-role \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": { "Service": "pods.eks.amazonaws.com" },
        "Action": [ "sts:AssumeRole", "sts:TagSession" ]
      }
    ]
  }'

# Attach Bedrock permissions
aws iam put-role-policy \
  --role-name remediator-agent-role \
  --policy-name BedrockInvokePolicy \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "BedrockInvoke",
        "Effect": "Allow",
        "Action": [
          "bedrock:InvokeModel",
          "bedrock:InvokeModelWithResponseStream"
        ],
        "Resource": "arn:aws:bedrock:<AWS_REGION>:<AWS_ACCOUNT_ID>:application-inference-profile/<PROFILE>"
      }
    ]
  }'

# Create Pod Identity association
aws eks create-pod-identity-association \
  --cluster-name <CLUSTER_NAME> \
  --namespace nirmata \
  --service-account remediator-agent \
  --role-arn arn:aws:iam::<ACCOUNT_ID>:role/remediator-agent-role

Using Azure OpenAI (Alternative):

# Create secret
kubectl create secret generic azure-openai-credentials \
  --from-literal=api-key=AZURE_API_KEY \
  -n nirmata

# Create LLMConfig
kubectl apply -f - <<EOF
apiVersion: serviceagents.nirmata.io/v1alpha1
kind: LLMConfig
metadata:
  name: remediator-agent-llm
  namespace: nirmata
spec:
  type: azure-openai
  azureOpenAI:
    endpoint: https://YOUR_RESOURCE_NAME.openai.azure.com/
    deploymentName: DEPLOYMENT_NAME
    apiKeySecretRef:
      name: azure-openai-api-key
      key: api-key
      namespace: nirmata
EOF

3. Setup Remediator

For ArgoCD Hub Mode (Multi-Cluster):

kubectl apply -f - <<EOF
apiVersion: serviceagents.nirmata.io/v1alpha1
kind: Remediator
metadata:
  name: remediator-argo-hub
  namespace: nirmata
spec:
  environment:
    type: argoHub
  
  target:
    argoHubTarget:
      argoAppSelector:
        allApps: true
  
  remediation:
    triggers:
      - schedule:
          crontab: "0 */6 * * *"
    llmConfigRef:
      name: remediator-agent-llm
      namespace: nirmata
    gitCredentials:
      name: toolconfig-sample
      namespace: nirmata
    eventPolling:
      enabled: true
      intervalMinutes: 5
    actions:
      - type: CreatePR
        toolRef:
          name: toolconfig-sample
          namespace: nirmata
EOF

For Local Cluster Mode:

First, create a ConfigMap mapping repositories to namespaces:

kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: repo-namespace-mapping
  namespace: nirmata
data:
  mapping: |
    [
      {
        "repo": "https://github.com/your-org/your-repo",
        "branch": "main",
        "path": "k8s/",
        "targetNamespace": "default"
      }
    ]
EOF

Then create the Remediator:

kubectl apply -f - <<EOF
apiVersion: serviceagents.nirmata.io/v1alpha1
kind: Remediator
metadata:
  name: remediator-local-cluster
  namespace: nirmata
spec:
  environment:
    type: localCluster
  
  target:
    localCluster:
      repoNamespaceMappingRef:
        name: repo-namespace-mapping
        namespace: nirmata
        key: mapping
  
  remediation:
    triggers:
      - schedule:
          crontab: "0 */6 * * *"
    llmConfigRef:
      name: remediator-agent-llm
      namespace: nirmata
    gitCredentials:
      name: toolconfig-sample
      namespace: nirmata
    eventPolling:
      enabled: true
      intervalMinutes: 5
    actions:
      - type: CreatePR
        toolRef:
          name: toolconfig-sample
          namespace: nirmata
EOF

Verify Installation

# Check if pods are running
kubectl get pods -n nirmata -l app.kubernetes.io/name=remediator-agent

# Check custom resources
kubectl get llmconfigs,toolconfigs,remediators -n nirmata

# Check logs
kubectl logs -n nirmata -l app.kubernetes.io/name=remediator-agent --tail=50

Advanced Configuration

Target Specific Clusters:

target:
  argoHubTarget:
    clusterNames:
      - production-cluster
      - staging-cluster
    clusterServerUrls:
      - "https://prod.example.com"
    argoAppSelector:
      allApps: true

Target Specific Applications:

target:
  argoHubTarget:
    argoAppSelector:
      names:
        - nginx-demo
        - web-app
      labelSelector:
        matchLabels:
          team: platform
          environment: production

Filter by Policy Severity:

remediation:
  filters:
    policySelector:
      matchSeverity:
        - high
        - critical

Configure Event Polling for PR Monitoring:

The agent can automatically poll Git pull requests for new comments and respond to them:

remediation:
  eventPolling:
    enabled: true
    intervalMinutes: 5  # Poll every 5 minutes (default)

Configure Actions with Confidence Levels:

Control when automated actions are triggered based on AI confidence levels:

remediation:
  actions:
    - type: CreatePR
      confidence:
        - high  # Only create PRs when AI has high confidence in the fix
      toolRef:
        name: toolconfig-sample
        namespace: nirmata
    - type: CreatePR
      confidence:
        - low   # Create PRs even with low confidence (for review)
      toolRef:
        name: toolconfig-sample-review
        namespace: nirmata

VCS Target Mode (Direct Repository Scanning):

Scan Git repositories directly without requiring cluster deployment:

apiVersion: serviceagents.nirmata.io/v1alpha1
kind: Remediator
metadata:
  name: remediator-vcs
  namespace: nirmata
spec:
  environment:
    type: localCluster  # or argoHub
  
  target:
    vcs:
      # Define policies and their Git locations
      policies:
        - name: pod-security-policy
          repo: https://github.com/your-org/policies
          path: kyverno/pod-security.yaml
          ref: main
        - name: resource-limits-policy
          repo: https://github.com/your-org/policies
          path: kyverno/resource-limits.yaml
          ref: main
      
      # Define resources and which policies to apply
      resources:
        - name: web-app-deployment
          repo: https://github.com/your-org/manifests
          path: deployments/web-app.yaml
          ref: main
          policyRefs:
            - pod-security-policy
            - resource-limits-policy
        - name: api-deployment
          repo: https://github.com/your-org/manifests
          path: deployments/api.yaml
          ref: main
          policyRefs:
            - pod-security-policy
  
  remediation:
    triggers:
      - schedule:
          crontab: "0 */6 * * *"
    llmConfigRef:
      name: remediator-agent-llm
      namespace: nirmata
    gitCredentials:
      name: toolconfig-sample
      namespace: nirmata
    actions:
      - type: CreatePR
        toolRef:
          name: toolconfig-sample
          namespace: nirmata

Observability

The Remediator Agent exposes Prometheus metrics for monitoring and troubleshooting.

Available Metrics

  • remediator_reconciles_total (counter) — labels: result=“success|error”
  • remediator_reconcile_duration_seconds (histogram) — labels: result=“success|error”

Quick Setup

Enable Service Monitor:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: go-agent-remediator-metrics
  namespace: go-agent-remediator-system
spec:
  selector:
    matchLabels:
      control-plane: controller-manager
  endpoints:
    - port: https
      path: /metrics
      scheme: https
      tlsConfig:
        insecureSkipVerify: true

View Metrics:

# Port-forward to metrics endpoint
kubectl -n go-agent-remediator-system port-forward deploy/go-agent-remediator-controller-manager 8443:8443

# Get token and view metrics
SA=go-agent-remediator-controller-manager
NS=go-agent-remediator-system
TOKEN=$(kubectl -n $NS create token $SA)
curl -k -H "Authorization: Bearer $TOKEN" https://localhost:8443/metrics

Example Prometheus Queries

# Success rate
sum(rate(remediator_reconciles_total{result="success"}[1h]))
/
sum(rate(remediator_reconciles_total[1h]))

# P95 latency
histogram_quantile(0.95, 
  sum by (le) (rate(remediator_reconcile_duration_seconds_bucket[1h]))
)

Split PR Feature

Overview

The Split PR feature allows you to split a pull request that contains remediations for multiple policies into separate PRs. This is useful when you want to review and merge policy remediations independently, or when some policies need different approval workflows.

When to Use Split PR

Use the split PR feature when:

  • Independent Review: You want to review and approve each policy remediation separately
  • Different Approval Workflows: Some policies require different reviewers or approval processes
  • Selective Merging: You want to merge some policy fixes immediately while others need more discussion
  • Reduced PR Complexity: Breaking down a large PR with many policy violations into smaller, focused PRs
  • Parallel Processing: Multiple teams can work on different policy remediations simultaneously

How It Works

When you split a PR:

  1. Original PR is updated to contain only the remaining policies (those not split out)
  2. New PR is created containing only the split policies you specified
  3. Both PRs are automatically updated with comments explaining what happened
  4. The remediator continues to track both PRs independently

Command Syntax

To split policies from a PR, add a comment to the PR with the following format:

@nirmatabot split-pr <policy-name-1> <policy-name-2> ...

Command Format:

  • Mention: Must start with @nirmatabot
  • Command: split-pr (case-sensitive)
  • Policies: One or more policy names, separated by spaces
  • Policy Names: Use the exact policy names as they appear in the PR

Examples:

Split a single policy:

@nirmatabot split-pr require-run-as-non-root

Split multiple policies:

@nirmatabot split-pr require-run-as-non-root disallow-privileged-containers

Review the Results

After processing, you’ll see:

On the Original PR:

  • A comment confirming the split
  • Link to the new PR
  • List of policies that were split
  • Count of remaining policies

On the New PR:

  • A comment explaining it was created from a split
  • Link back to the original PR
  • List of policies in this PR

What Happens During a Split

Original PR Changes:

  • Content Updated: The PR content is updated to remediate only the remaining policies
  • Policies List: The list of tracked policies is updated to exclude split policies
  • Branch: The original branch remains the same
  • History: All commit history is preserved

New PR Creation:

  • New Branch: A new branch is created with a unique name (prefixed with splitpr-)
  • New Content: Contains remediated content for only the split policies
  • Target Branch: Targets the same branch as the original PR
  • Tracking: The new PR is automatically tracked in the RemediationRecord

Monitoring Remediator Status

The Remediator resource provides detailed status information about remediation runs:

# View Remediator status
kubectl get remediators -n nirmata -o yaml

# Check last run summary
kubectl get remediator remediator-argo-hub -n nirmata -o jsonpath='{.status.lastRunSummary}' | jq

Status Fields

The Remediator status includes:

  • phase: Current operational phase (e.g., Running, Idle, Failed)
  • lastScheduleTime: When the last remediation was scheduled
  • lastSuccessfulTime: When the last successful run completed
  • nextScheduledTime: When the next run is scheduled
  • conditions: Detailed workflow step tracking with collector information
  • lastRunSummary: Comprehensive details about the most recent run:
    • startTime / endTime: Run duration
    • status: Success or failure indication
    • message: Details about the outcome
    • targetsProcessed: Number of targets scanned
    • violationsFound: Total violations discovered
    • remediationPlans: Number of AI-generated remediation plans
    • actionsExecuted: Number of actions performed (PRs created, etc.)
    • errors: Any errors encountered during the run

Example Status Query

# Get summary of last run
kubectl get remediator remediator-argo-hub -n nirmata -o jsonpath='{.status.lastRunSummary}' | jq '{
  status: .status,
  duration: (.endTime | . - .startTime),
  violations: .violationsFound,
  actions: .actionsExecuted,
  errors: .errors
}'

Support Matrix

  • Kubernetes: All CNCF compliant distributions (v1.20+), including vanilla K8s and on-prem
  • AI Providers: Nirmata AI (default), AWS Bedrock, Azure OpenAI
  • GitOps: ArgoCD
  • VCS: GitHub (App & PAT), GitLab (Enterprise & SaaS)
  • Manifests: YAML files, simple Helm charts

Common Use Cases

  • Policy Compliance Automation: Automatically fix security policy violations across your clusters
  • GitOps Integration: Generate pull requests with fixes that integrate with your GitOps workflows
  • Multi-Cluster Management: Manage policy compliance across multiple clusters from a central hub
  • Continuous Compliance: Achieve continuous compliance instead of point-in-time checks

Uninstallation

helm uninstall remediator -n nirmata

Note: This removes the deployment and CRDs but preserves any secrets you have created. They need to be cleaned up manually.

Value Proposition

By deploying the Remediator Agent, platform engineering teams can:

  • Operate at Scale: Manage 10x more clusters without proportional team growth
  • Reduce Toil: Eliminate 80% of repetitive compliance and governance tasks
  • Improve Compliance: Achieve continuous compliance instead of point-in-time checks
  • Faster Remediation: Reduce resolution times from days to minutes
  • Better Security Posture: Catch and fix vulnerabilities before they’re exploited
  • Empower Developers: Provide fast feedback and automated fixes to development teams

The Remediator Agent doesn’t replace platform engineers—it amplifies their capabilities, allowing them to focus on innovation and strategic work while ensuring operational excellence at scale.

API Reference

Remediator Spec

Environment

environment:
  type: localCluster | argoHub  # Required

Target

target:
  # Option 1: Local Cluster Target
  localCluster:
    repoNamespaceMappingRef:
      name: string          # Required: ConfigMap name
      namespace: string     # Optional: ConfigMap namespace
      key: string          # Optional: Key in ConfigMap (default: "mapping")
  
  # Option 2: ArgoCD Hub Target
  argoHub:
    clusterNames:          # Optional: List of cluster names
      - string
    clusterServerUrls:     # Optional: List of cluster server URLs
      - string
    appSelector:           # Required: How to select applications
      allApps: boolean     # Select all applications
      names:              # Specific application names
        - string
      labelSelector:      # Label-based selection
        matchLabels:
          key: value
        matchExpressions:
          - key: string
            operator: In | NotIn | Exists | DoesNotExist
            values:
              - string
  
  # Option 3: VCS Target (Direct repository scanning)
  vcs:
    policies:              # Required: Policy definitions
      - name: string       # Policy name
        repo: string       # Git repository URL
        path: string       # Path to policy file
        ref: string        # Git reference (branch/tag/commit)
    resources:             # Required: Resource definitions
      - name: string       # Resource name
        repo: string       # Git repository URL
        path: string       # Path to resource file
        ref: string        # Git reference
        policyRefs:        # Policies to apply to this resource
          - string

Remediation

remediation:
  llmConfigRef:            # Required: Reference to LLMConfig
    name: string           # Required
    namespace: string      # Optional
    apiVersion: string     # Optional (default: serviceagents.nirmata.io/v1alpha1)
    kind: string          # Optional (default: LLMConfig)
  
  gitCredentials:          # Optional: Reference to ToolConfig for Git auth
    name: string
    namespace: string
    apiVersion: string
    kind: string
  
  triggers:                # Required: When to run remediation
    - schedule:
        crontab: string    # Cron expression
  
  filters:                 # Optional: What to remediate
    policySelector:
      matchSeverity:       # Filter by severity
        - string
  
  eventPolling:           # Optional: PR event polling configuration
    enabled: boolean       # Default: true
    intervalMinutes: int   # Default: 5, minimum: 1
  
  actions:                # Required: What actions to take
    - type: string        # Action type (e.g., "CreatePR")
      confidence:         # Optional: Confidence levels that trigger action
        - high | low
      toolRef:            # Required: Reference to ToolConfig
        name: string
        namespace: string
        apiVersion: string
        kind: string

LLMConfig Spec

spec:
  type: nirmataAI | bedrock  # Required
  
  # For Nirmata AI
  nirmataAI:
    endpoint: string                  # Required
    model: string                     # Required
    apiKeySecretRef:                  # Required
      name: string                    # Secret name
      namespace: string               # Secret namespace
      key: string                     # Key in secret
  
  # For AWS Bedrock
  bedrock:
    model: string                     # Required: Model ID or inference profile ARN
    region: string                    # Required: AWS region
    roleArn: string                   # Optional: IAM role ARN
    externalId: string                # Optional: External ID for role assumption
    credentialsSecretRef:             # Optional: AWS credentials
      name: string
      namespace: string
      key: string
  
  # For Azure OpenAI
  azureOpenAI:
    endpoint: string                  # Required: Azure OpenAI endpoint
    deploymentName: string            # Required: Deployment name
    apiKeySecretRef:                  # Required
      name: string
      namespace: string
      key: string

ToolConfig Spec

spec:
  type: github | gitlab               # Required
  
  credentials:                        # Required
    method: pat | app                 # Required
    
    # For Personal Access Token
    pat:
      tokenSecretRef:
        name: string                  # Required
        namespace: string             # Optional
        key: string                   # Required
    
    # For GitHub App
    app:
      appId: int64                    # Required
      installationId: int64           # Optional: Auto-discovered if not set
      privateKeySecretRef:
        name: string                  # Required
        namespace: string             # Optional
        key: string                   # Required
  
  defaults:                           # Optional
    git:
      pullRequests:
        branchPrefix: string          # PR branch prefix
        titleTemplate: string         # PR title template
        commitMessageTemplate: string # Commit message template
        customLabels:                 # Static labels
          - string
        systemLabels:                 # Dynamic labels (max 20)
          - branch | clusterName | appName | namespace
GitHub Authentication Guide

Complete guide to GitHub authentication methods for Nirmata AI Agents