Access Control

Operations can specify an access: attribute to control their visibility and usage.

Access Levels

public (default)

Public operations can be:

Run directly via dyngle run
Exposed as tools through the MCP server
Listed in dyngle list-operations output

dyngle:
  operations:
    deploy:
      access: public  # Explicitly public (default if omitted)
      description: Deploy to production
      steps:
        - sub: build
        - aws s3 sync ./dist s3://my-bucket/

If access: is not specified, operations default to public.

private

Private operations can only be called as sub-operations by other operations. They cannot be:

Run directly via dyngle run (will fail with an error)
Exposed through the MCP server
Listed in dyngle list-operations output

dyngle:
  operations:
    build:
      access: private
      steps:
        - npm install
        - npm run build
    
    deploy:
      steps:
        - sub: build  # OK - called as sub-operation
        - aws s3 sync ./dist s3://my-bucket/

Attempting to run a private operation directly:

dyngle run build

Results in an error:

Error: Operation 'build' is private and cannot be run directly

Use Cases for Private Operations

Helper Operations

Extract common functionality into private helpers:

dyngle:
  operations:
    setup-environment:
      access: private
      steps:
        - echo "Setting up environment..."
        - export NODE_ENV=production
    
    deploy-frontend:
      steps:
        - sub: setup-environment
        - npm run deploy:frontend
    
    deploy-backend:
      steps:
        - sub: setup-environment
        - npm run deploy:backend

Secret Management

Prevent accidental exposure of operations that handle secrets:

dyngle:
  operations:
    get-api-token:
      access: private
      return: token
      steps:
        - aws secretsmanager get-secret-value --secret-id api-token => secret
        - secret -> jq -r '.SecretString' => token
    
    call-api:
      description: Make authenticated API call
      steps:
        - sub: get-api-token
          => token
        - curl -H "Authorization: Bearer {{token}}" https://api.example.com/data

This prevents:

Running dyngle run get-api-token accidentally
Exposing the token operation through the MCP server
Listing the sensitive operation in dyngle list-operations

Internal Implementation Details

Hide implementation details from users:

dyngle:
  operations:
    validate-config:
      access: private
      steps:
        - cat config.yml => config
        - config -> python validate.py
    
    transform-data:
      access: private
      steps:
        - cat data.json => raw
        - raw -> jq '.items' => items
    
    process:
      description: Process data with validation
      steps:
        - sub: validate-config
        - sub: transform-data
        - echo "Processing complete"

Users only see and can run process, not the internal helpers.

Multi-Step Workflows

Build complex workflows from smaller private operations:

dyngle:
  operations:
    install-dependencies:
      access: private
      - npm install
    
    run-tests:
      access: private
      - npm test
    
    build-artifacts:
      access: private
      - npm run build
    
    upload-artifacts:
      access: private
      - aws s3 sync ./dist s3://my-bucket/
    
    ci-pipeline:
      description: Run full CI/CD pipeline
      steps:
        - sub: install-dependencies
        - sub: run-tests
        - sub: build-artifacts
        - sub: upload-artifacts

Interaction with MCP Server

When running as an MCP server:

Public operations are exposed as tools that AI assistants can discover and use
Private operations are not exposed and cannot be called by AI assistants

This is important for security - private operations containing sensitive logic or credentials won't be accidentally triggered by AI assistants.

Best Practices

Make Public Operations User-Facing

Public operations should represent complete, user-facing actions:

dyngle:
  operations:
    deploy:
      description: Deploy application to production
    
    test:
      description: Run the test suite
    
    build:
      description: Build the application

Make Private Operations Modular

Private operations should be focused, reusable components:

dyngle:
  operations:
    setup-env:
      access: private
      # Focused: just environment setup
    
    validate:
      access: private
      # Focused: just validation
    
    upload:
      access: private
      # Focused: just uploading

Use Descriptive Names

Since private operations won't be listed, use clear names that indicate their purpose:

dyngle:
  operations:
    _internal_cleanup:  # prefix convention for internal ops
      access: private
    
    _fetch_credentials:
      access: private

Dyngle