Best practices

Recommendations for effectively integrating licit into your AI-assisted development workflow.


Initial setup

1. Initialize from the start

Run licit init at the beginning of the project, not after the fact. The sooner you start tracking, the more complete your compliance evidence will be.

mkdir mi-proyecto && cd mi-proyecto
git init
# ... initial setup ...
licit init
git add .licit.yaml
git commit -m "feat: initialize licit compliance tracking"

2. Commit .licit.yaml

The configuration file should be version-controlled. The entire team should use the same configuration.

git add .licit.yaml

3. Configure .gitignore correctly

# Sensitive licit data
.licit/provenance.jsonl
.licit/fria-data.json

# Signing key
.licit/signing-key

# Generated reports (optional — can be included)
# .licit/reports/

4. Select the relevant frameworks

Do not enable frameworks that do not apply to your context:

# If your product does not operate in the EU:
frameworks:
  eu_ai_act: false
  owasp_agentic: true

# If you only need EU AI Act:
frameworks:
  eu_ai_act: true
  owasp_agentic: false

Provenance traceability

5. Run trace regularly

Run licit trace after each sprint or release to keep traceability up to date:

licit trace --since 2026-03-01 --stats --report

Combine git heuristics with session logs for greater accuracy:

provenance:
  methods:
    - git-infer
    - session-log
  session_dirs:
    - ~/.claude/projects/

6. Enable signing in regulated environments

If you need to demonstrate integrity of the provenance chain:

provenance:
  sign: true
  sign_key_path: ~/.licit/signing-key

Generate a secure key:

python3.12 -c "import secrets; print(secrets.token_hex(32))" > ~/.licit/signing-key
chmod 600 ~/.licit/signing-key

7. Adjust the confidence threshold

The default (0.6) is conservative. Adjust according to your context:

provenance:
  # Stricter (fewer AI false positives)
  confidence_threshold: 0.8

  # More permissive (detects more AI code, more false positives)
  confidence_threshold: 0.4

AI agent configuration

8. Document your agents

Maintain explicit agent configuration files:

CLAUDE.md              # Instructions for Claude Code
.cursorrules           # Rules for Cursor
AGENTS.md              # GitHub Agents configuration

licit monitors these files automatically and records changes.

9. Implement guardrails

In your architect or other agent configuration, define:

# .architect/config.yaml (example)
guardrails:
  protected_files:
    - .env
    - secrets.yaml
    - migrations/
  blocked_commands:
    - rm -rf
    - DROP TABLE
  code_rules:
    - "no eval() or exec()"
    - "all API endpoints require authentication"

licit counts these guardrails as compliance evidence.

10. Require human review in CI/CD

Configure your pipeline to require human approval before deployment:

# .github/workflows/deploy.yml
jobs:
  deploy:
    environment: production   # Requires approval in GitHub
    steps:
      - name: Compliance check
        run: licit verify
      - name: Deploy
        run: ./deploy.sh

licit detects the presence of environment: in GitHub Actions as evidence of a human review gate.


Continuous compliance

11. Integrate licit verify into CI/CD

Add a compliance check on every PR:

# .github/workflows/compliance.yml
name: Compliance
on: [pull_request]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install licit-ai-cli
      - run: licit verify

12. Generate agent config changelogs

Run licit changelog regularly to document changes in your AI agent configuration. This is key evidence for compliance:

licit changelog                        # Markdown by default
licit changelog --format json          # JSON for integration
licit changelog --since 2026-03-01     # From a specific date

The changelog classifies each change as MAJOR (model/provider), MINOR (prompt/guardrails/tools), or PATCH (tweaks). MAJOR changes deserve special attention — they can affect agent behavior.

git add .licit/changelog.md
git commit -m "docs: update agent config changelog"

13. Generate reports periodically

Do not wait for the audit. Generate reports on every release:

# Before each release
licit trace --report
licit changelog
licit report --format markdown
git add .licit/reports/ .licit/changelog.md
git commit -m "docs: update compliance report for v1.2.0"

14. Review gaps regularly

licit gaps

Prioritize closing the highest-priority gaps first.


Connectors

15. Enable connectors when possible

If you use Architect or Vigil, enable them. They provide additional evidence:

licit connect architect
licit connect vigil

Architect provides:

Vigil provides:

16. Integrate security tools

licit automatically detects these tools and uses their results as evidence:

ToolWhat it detects
SemgrepInsecure code patterns
SnykDependency vulnerabilities
CodeQLStatic security analysis
TrivyContainer vulnerabilities
ESLint SecurityJavaScript security rules

Team organization

17. Designate a compliance lead

Someone on the team should be responsible for:

18. Document decisions

When a requirement is marked as n/a (not applicable), document why. This is important for audits:

# In your FRIA or internal documentation:
Art. 10 (Data Governance): N/A — This system does not train models,
it only uses pre-trained models via API.

19. Keep the configuration up to date

When you switch AI tools, update the configuration:

# After migrating from Cursor to Claude Code
licit init  # Re-detects the project
licit status  # Verify detection

Anti-patterns to avoid

Anti-patternWhy it is problematicWhat to do instead
Ignoring licit verify warningsPartial findings accumulateTreat partials as technical debt
Not version-controlling .licit.yamlEach dev uses a different configCommit to the repo
Pushing provenance.jsonl to a public repoExposes contributor infoAdd to .gitignore
Generating reports only before auditsIncomplete evidenceGenerate on every release
Disabling signing “because it’s slow”Loss of verifiable integritySign at least in CI
Not updating the FRIAAn outdated FRIA has no valueUpdate with every significant change
Marking everything as n/aCompliance evasionJustify each n/a in writing