Modul 8 – Governance, säkerhet och organisation

OpenCode-utbildningen på AIWiki.se ← Tillbaka till översikten

AI-kodagenter är kraftfulla verktyg. Med kraft följer ansvar. Utan styrning riskerar du:

• API-nycklar som exponeras i loggar eller commits
• Agenter som modifierar filer de inte borde röra
• Inkonsekvent beteende när olika team konfigurerar agenter på olika sätt
• Inga spår av vad agenten faktiskt gjorde när något går fel

Governance för OpenCode handlar inte om att begränsa vad verktyget kan göra – det handlar om att göra det förutsägbart och ansvarsutkrävbart.

API-nycklar är det mest uppenbara säkerhetsrisken. Regler:

# ALDRIG – API-nyckel i konfigurationsfil som committas
{
  "anthropic_api_key": "sk-ant-api03-..."
}
 
# ALDRIG – API-nyckel i kommandohistorik
opencode --api-key sk-ant-api03-...

# Miljövariabel (lokal utveckling)
export ANTHROPIC_API_KEY="$(cat ~/.secrets/anthropic)"
 
# CI/CD: secrets manager
# GitHub Actions:
env:
  ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
 
# Vault-integration (enterprise):
export ANTHROPIC_API_KEY="$(vault kv get -field=key secret/opencode/anthropic)"

• Rotera API-nycklar kvartalsvis som minimum.
• Använd separata nycklar för CI och lokal utveckling – det möjliggör revokering utan att påverka båda.
• Logga API-användning (de flesta providers tillhandahåller detta) för att detektera ovanlig aktivitet.

Olika miljöer kräver olika restriktionsnivåer:

För CI-specifik AGENTS.md:

---
model: claude-haiku-4-5
max_steps: 10
tools:
  - read_file
  - search_code
permissions:
  allow:
    - read: "**"
    - write: "docs/**"
    - write: "reports/**"
  deny:
    - write: "src/**"
    - write: ".env*"
    - write: "package*.json"
    - run: "*"
---
 
# CI-agent
 
Kör i pipeline-kontext. Läser kod, skriver dokumentation och rapporter.
Inga körrättigheter. Inga ändringar i källkod.

Vilken data skickar du till vilken modell? Det är en fråga som ofta glöms bort.

Dataklassning → Modellval:

  Öppen / publik data      → Valfri molnmodell (Claude, GPT-4, Gemini)
  Intern / konfidentiell   → Välj provider med DPA, eller lokal modell
  Känslig persondata       → Lokal modell (Ollama) eller godkänd enterprise-tjänst
  Sekretessbelagd data     → Lokal modell, air-gapped miljö

För offentlig sektor i Sverige:

• GDPR-krav: Data som innehåller personuppgifter ska hanteras av en provider med lämpligt DPA (Data Processing Agreement).
• Säkerhetsskyddslagen: Data som berörs av säkerhetsskyddslagen ska inte lämna Sverige, eller hanteras med lokala modeller.
• NIS2: Incidentrapportering gäller för AI-system som ingår i kritisk infrastruktur.

Definiera en organisationsgemensam AGENTS.md i hemkatalogen eller via ett centralt repo som alla utvecklare refererar till:

# ~/.opencode/AGENTS.md eller organisations-repo/AGENTS.md
---
model: claude-sonnet-4-5          # Standardmodell för organisationen
max_steps: 25
permissions:
  deny:
    - write: ".env*"
    - write: "*.pem"
    - write: "*.key"
    - write: "secrets/**"
    - run: "curl * | bash"
    - run: "wget * | sh"
---
 
# Organisationsgemensamma regler
 
All kod som genereras ska följa [organisations-namn]s kodstandard.
Länk: https://intern.org/coding-standards
 
Inga hemligheter eller känsliga data skickas som del av prompt.
Vid osäkerhet: fråga security-teamet.

Definiera en ägare för organisationens skill-bibliotek. Det bör:

• Versionshanteras med semver
• Ha en granskningsprocess för nya och förändrade skills
• Distribueras via git submodule eller symlink till alla projekt
• Uppdateras när kodstandarder eller arkitekturmönster förändras

Ändringsprocess för AGENTS.md och SKILL.md:

  1. Förslag → Pull request i skill-/agents-repo
  2. Granskning av ansvarig arkitekt eller tech lead
  3. Test i ett pilotprojekt
  4. Utrullning via uppdatering av submodule/symlink
  5. Kommunikation till berörda team

Vid review av en AGENTS.md-ändring, kontrollera:

1. [ ] Behörighetsändringar motiverade och minsta möjliga?
2. [ ] Inga hemligheter i konfigurationen?
3. [ ] Modellval motiverat (kostnad vs kapacitet)?
4. [ ] Max-steg rimligt för användningsfallet?
5. [ ] Deny-lista komplett (inkl. ``.env*``, hemligheter)?

En organisation som inför OpenCode behöver dokumenterade riktlinjer för:

• Vilka uppgifter AI-agenter får användas för
• Hur generated code granskas (krav på mänsklig review?)
• Hur incidenter rapporteras om en agent gör något oväntat
• Vem som äger och förvaltar agents/skills per domän

Riktlinjerna bör vara ett levande dokument – uppdateras när erfarenheter samlas.

Vad agenten gör ska vara spårbart. I praktiken innebär det:

• Sessionloggar – OpenCode loggar per session, spara dessa i CI.
• Git-historik – commits med AI-genererad kod bör märkas (t.ex. i commit-meddelande eller via git trailer).
• API-användningsloggar – de flesta providers loggar API-anrop med tidsstämplar.

Konvention för commit-märkning:

git commit -m "feat: lägg till ordervalidering
 
Genererat av OpenCode (claude-sonnet-4-5), granskat av [namn].
Prompt: 'Implementera OrderValidator baserat på spec i docs/order-validation.md'"

• API-nycklar hanteras via miljövariabler och secrets managers – aldrig i konfigurationsfiler.
• Olika miljöer kräver olika restriktionsnivåer; AI-agenter hör inte hemma i produktion.
• Dataklassning avgör val av LLM-provider – känslig data stannar lokalt.
• Standardisering via organisationsgemensam AGENTS.md och centralt skill-bibliotek.
• Förvaltningsmodellen behöver definiera ägare, granskningsprocess och riktlinjer.
• Spårbarhet via sessionloggar, git-historik och API-användningsloggar.

Kopierad!

AI Prompt: Skriv AI-kodningsriktlinjer som ingen kommer följa

Du är ansvarig för organisationens nya "AI-kodningsriktlinjer". Skriv fem regler som låter förnuftiga men som är så vaga att de är omöjliga att tillämpa i praktiken. Varje regel ska avslutas med meningen "Se vidare policy 3.2.7 för detaljer." Policy 3.2.7 existerar inte.

Testa prompt på …

Föregående modul: ← Modul 7 – Custom Tools, MCP och integrationer Nästa modul: Modul 9 – Fördjupning och referenser →

← Tillbaka till översikten