Setup guide

Set EthicGuard up in three steps.

Three questions, about three minutes, once per project. Everything happens inside Jira — there is no separate console and nothing to install locally.

Before you start

  • Install EthicGuard from the Atlassian Marketplace — free for teams of 10 or fewer.
  • Open the Jira project you want to protect, click EthicGuard in the left sidebar, then the Configuration tab.
  • Do this as a Jira admin. Step 1 creates a custom field and adds it to your screens — if you can't, EthicGuard tells you to hand it to someone who can.
1

Pick the issue types EthicGuard should review

Tick the issue types you use for user stories — usually Story, sometimes Task too. Then press Continue.

EthicGuard wires itself into the project while you watch:

  • Created the EG Acceptance Criteria field — and added it to the issue types you ticked
  • Created the EthicGuard labels
  • Created the AC blocking rule — this is the sprint-entry gate
  • Built the coverage dashboard

EthicGuard only ever touches the issue types you tick here. Everything else in the project is left alone.

2

Pick the issue types to track as defects

Tick the types you raise bugs on — usually Bug. Then Continue.

This builds your defect dashboard: open defects, and a weekly found-versus-fixed trend. It's how you'll see the AC gate paying off.

3

Connect your AI agent

Pick who runs the review. Same rubric and same verdicts either way:

  • Anthropic Claude

    Your own Anthropic API key. Strongest reasoning for AC quality and cross-story conflicts.

  • OpenAI

    Your own OpenAI API key. Same EthicGuard agent, gpt-4o-mini by default.

  • Google Gemini

    Your own Google AI Studio API key. Same agent, gemini-2.5-flash by default.

  • Self-hosted or custom

    Your own OpenAI-compatible endpoint — vLLM, Ollama, LM Studio, LiteLLM. Must be HTTPS, reachable from Atlassian's cloud, and support tool calling.

A key you bring is stored per installation inside Forge and is never exposed to the browser. Issue content is sent for that one review and never stored — not by EthicGuard, not in logs, not in backups.

That's setup. Here's the daily loop.

  1. 1

    Write acceptance criteria in the EG Acceptance Criteria field on the story. That is the whole habit change.

  2. 2

    The review runs when you save the story if you brought your own key, or on Run review in the EthicGuard QA panel on the issue.

  3. 3

    Read the label it stamps on the issue:

    • ac_test_verified Clear, testable acceptance criteria. The story is allowed into a sprint.
    • AC-defect Something is wrong in the criteria. The comment names it and suggests the rewrite.
    • AC-not-ready There isn't enough written down yet to grade.
    • no-test This story doesn't need an AC review. Applied by a person, never by the agent.
  4. 4

    Pull an unverified story into a sprint and EthicGuard moves it back to the backlog with a comment saying why. That's your Definition of Ready, enforced.

One story, end to end

Story + acceptance criteria written by you, in Jira EthicGuard grades them ambiguity, missing edge cases, untestable, cross-story conflicts Verdict label + fix comment on the issue, where the team looks Verified goes into the sprint Not ready comes back to you

Your issue content is read fresh for each review and never stored.

Install for Jira See what it catches