Team Security

The team Security page lives under iKASecure in the top bar. It is scoped to a team and groups code findings, AI endpoint findings, hardening controls, and the workspace audit log. Available tabs depend on workspace entitlements and, for the audit log, the signed-in user's workspace role.

Open the security page

1. Select iKASecure in the top bar. It opens the last team you used, or your first team.
2. Select the required team under Your teams in the left sidebar. To see every team at once, select All teams above that list.
3. Start on OWASP Top 10 to review code-security findings.
4. Open Infrastructure for the infrastructure and runtime controls (cloud audit, runtime scanning, database isolation and review, API scan, container/image scanning and IaC scanning), and Non-OWASP Controls for the other hardening controls. Both need the security entitlement. Each tab's number counts its own Missing, Planned and Not checked yet controls; the ? next to the tabs lists which statuses it counts.
5. Open OWASP LLM Top 10 to review AI endpoint findings when your plan includes aiRedTeam. On a plan without it (Pro), iKASecure → Overview, All teams and Applications show the note "AI findings need the Pro+ plan" and count no AI findings; they do not open the upgrade popup.
6. Open Audit Log when the workspace has the auditLog entitlement and your role is Owner or Admin.

Tabs hidden by an entitlement or role cannot be opened from this page. The server enforces these checks as well as the page, so the visible navigation is not the security boundary.

Insights

With the security entitlement, Insights sits above the tabs. It shows together what each folded row says on its own, and its counts equal Overview for the team (every source: your code, packages, AI endpoints and infrastructure).

• Open, Critical open, Fixed, Fix rate and With fix task. Fix rate is fixed ÷ found over every scan. Accepted risks and false positives are not counted as fixed. With fix task counts open findings that have a task on the board.
• Found vs fixed, per scan day: bars for what each day's scans found and fixed, and a line for what was still open at the end of that day. Times come from the findings themselves (found, fixed, or a person's verdict), never from an estimate.
• Scans at a glance: one line per scan with its open findings by severity, the time it was checked, and the row's own status (Enforced, Advisory, Missing, Not checked yet). A line reads Scanning… since time while that scan runs. Select a line to open its row; Packages opens Applications.
• Recent scans, a second tab in the same panel: the last ten publishes, with what each found (+) and fixed (−). Runs from before this block show —.
• Hide folds the block; the page remembers it in this browser.

Team tabs on Overview, All teams and Applications

Overview, All teams and Applications show the same row of team tabs: All teams, then one tab for each of your teams. Select a tab to see only that team's findings, severity counts, scans, rules and applications.

• The team stays in the address (for example ?team=IKA), so a reload, a shared link, and the Back and Forward buttons keep it.
• The team carries across pages: See all findings on Overview, the Overview, All teams and Applications links in the sidebar, and Run a scan, which starts on that team.
• A team under Your teams opens that team's Overview tab. Its own page (OWASP groups, controls, audit log) opens with OWASP & controls at the top of Overview; that page has no dependency findings, so the tab is the count to trust.
• Export, See all findings and Run a scan sit at the top of Overview, next to its title. Export saves the source and team tables, with Fix first, as CSV or a PDF report. In the tables, Closed counts findings that were fixed, accepted as a risk or marked a false positive.
• Run a scan publishes to the tab's team. On All teams, pick a team first.
• With only one team you see no tab row. A team you are not in, or an unknown team in the address, opens All teams.

Scans

All teams → Scans shows one row per scanned AI endpoint, and one row per code, infrastructure or repository-controls target, newest scan first.

• Each row shows its newest scan. Earlier scans of the same target fold under N earlier runs.
• Partial means the run tested fewer attack categories than exist, so Nothing found covers only those categories.
• A code, infrastructure or repository-controls row shows how many findings its scan found and closed. Incomplete means a part of the scan did not run, so it closed nothing. The rows come from the newest 10 recorded runs of each scan and target.
• See findings opens Findings narrowed to that row, fixed findings included.
• The full report is on the machine that ran the scan, not in iKanban. On that machine, npx -y ikanban@latest scans list lists its scans and npx -y ikanban@latest scans show <id> opens one.

Run a scan

Run a scan opens one panel. An agent does the work: it runs the scanners from the npm package ikanban (npx -y ikanban@latest secscan), maps your folders to the team's applications, and publishes. You download nothing and type no command.

1. Pick What to scan: Everything, Code, AI endpoints, Dependencies, Containers & IaC, Web app (DAST), API (OpenAPI), AWS account, Repository controls or Imported report. Code and Dependencies are the same scan run.
2. Pick the Team the findings go to.
3. Select Send to my runner to start a session on your laptop's iKanban runner in the repository shown, with the agent shown (Claude, Copilot or Antigravity). Or select Copy prompt and paste it into any coding agent opened in the repository.
4. The agent replies with one list: findings per severity, what it filed, which folders it mapped to which application, and what it skipped and why.

Send to my runner logs a task in your iKAgent home team and opens its session. The session shows what you asked for, for example Scan: code and dependencies; the full instructions sent to the agent stay folded under Scan instructions sent to the agent.

Applications. A dependency scan files its findings to an application of the team. A team starts with none. Add them in iKASecure → Run a scan → Applications, one per folder with a package manifest (for example backend and frontend), or ask an agent to do it with security_create_application. Run a scan shows that field for Dependencies, Code and Everything, lists the team's applications, and warns when there are none. The Applications page lists every scanned row and has a Run a scan button. Open counts findings not fixed yet (open, being fixed or in review); Closed counts fixed, accepted and false-positive ones. Last scan is when a scanner last checked the row: the newest AI run, or recorded code, dependency or infrastructure scan; "—" means no scan of it was recorded yet. Select a row or a box to open All teams → Findings with exactly that application's findings, open and closed; the Application filter chip there removes the filter. Names use lowercase letters, digits, ., _ and -.

A team that was never scanned reads Never scanned. Run a scan to see what it finds. Nothing needs attention appears only after a scan found nothing open.

The prompt is the same text as .iKanban/prompts/security-scan.md and the ikanban-security-scan skill in the laptop kit. What decides whether a part runs:

• Copy prompt reads the iKanban key from .iKanban/settings-local.json (laptop setup writes it). The key never appears in the prompt.
• The prompt names this iKanban server and the team you picked. A repository's own settings file cannot send the key anywhere else: an address other than api.i-kanban.com or dev-api.i-kanban.com stops the scan.
• Every finding is cleaned before it is stored: a secret-looking value keeps its first 4 characters, and a home folder becomes ~. No report file is stored. See What a scan sends, and what stays on your machine below.
• On the runner, a scan sent with Send to my runner follows Agent settings → Runners → Risky actions like any other session, and the panel shows that rule. A scan has no extra allowance: the scanners send findings only, so there is no report upload to allow. Antigravity follows its own allow and deny rules instead.
• For AI endpoints the agent writes aiscan.toml at the repository root, and reuses it on the next scan.
• Run it yourself (closed at first) keeps the manual way: what the scan needs (Node.js 18 and python3), and the npx commands, including import for another scanner's report.

What a scan sends, and what stays on your machine

Scans run on your machine. The full report stays encrypted on that machine. Only findings, with secrets cut, are sent to iKanban.

• Read a report: on the machine that ran the scan, npx -y ikanban@latest scans list lists the scans, and npx -y ikanban@latest scans show <id> prints one to the terminal. Add a file name to print one file, and --out FILE to write it to a file. The scan id is not sent to iKanban, so list it on that machine.
• Old scan folders: earlier scanners kept plain-text reports in .iKanban/scans/ inside the repository. npx -y ikanban@latest scans migrate --path . seals them into the store and removes the plain copies.
• An old scanner: iKanban no longer stores full reports. A scanner or prompt that still uploads one gets a 410 answer: Update the iKanban CLI (npx -y ikanban@latest): full reports now stay encrypted on your machine; only findings are sent. Run the scanner again with npx -y ikanban@latest, or copy the current prompt from Run a scan.
• Reports filed before this change were team documents. They are deleted after the new scanner release.

Non-OWASP Controls

The Non-OWASP Controls tab lists ten controls. Each one shows which check sets its status:

• A repository control passes after a complete controlscan run in the last 30 days with no open finding of that check. An open Low finding makes it Advisory; Medium or worse makes it Missing. With no such run it reads Not checked yet.
• A failed check files one finding inside its control row: Medium for a fail, Low for a warning. These findings show on this tab only, not on OWASP Top 10.
• controlscan reads only the repository, plus the GitHub API through your own gh sign-in for branch protection. Without gh, that check reads skipped, never a pass.
• A control that no check covers reads Manual: a person set its status by hand, so it never reads as a checked result.

Findings and controls

The OWASP Top 10 view groups code findings by category; expand a category to inspect finding titles, locations, severity, and status. The Infrastructure and Non-OWASP Controls views group controls by domain; expand a control to inspect its threat/goal and source, and on Infrastructure the findings of its scan. For a missing control, + Task creates a remediation task in the team's default project. These views are not a live scan of the repository: the page presents findings and control data published to iKanban.

To scan, select Run a scan on the team page. It opens the same panel as on Overview, set to this team, so every scan logs a task and a session in iKAgent. The panel's closed Run it yourself gives the npx commands for a manual run. The scanners reach you only through npm; iKanban no longer serves a scanner file. The scanner can publish results back to this page when run with --publish. It sends your API key only to iKanban's API (https://api.i-kanban.com, https://dev-api.i-kanban.com, or a server on your own machine) and never follows a redirect with it; any other --base-url stops the scanner before it sends anything. With --publish it records the run under Scans, and files each committed secret (A07) and risky file permission (A05) as a finding on this page. Dependency findings are filed only for an application the team has: run --list-apps to see the names, then add --app FOLDER=NAME for each folder that holds one (for example --app vibe-backend=backend). Without --app, dependency findings stay in the local report and reach no count. A rescan closes what it no longer finds, only for the same repository and, with --app, the same application. It files what is new and re-opens a finding marked fixed that it finds again. The scanner prints how many closed and re-opened. False positive and accepted findings never change, and a rescan never files the same flaw again as a new open finding. For a dependency, the same flaw means the same package and the same CVE id; a verdict on a finding with no CVE id does not hide a later one. A closed finding's fix task stays as it is, like Mark fixed. A dependency scan with a skipped auditor closes nothing in that application. Findings filed by a scanner older than 1.2.0 close only after a rescan reports them once. New numbers show when an agent's scan session ends, and on the next page visit or tab focus. A dependency upload names its team, and an application of another team is refused. On iKASecure → Applications, each application row shows its open and total findings: a dependency finding under its application, an AI finding under its endpoint, and a code finding under the team's Code scans row, because code findings do not name a repository. The rows of each kind add up to that kind's count on iKASecure → Overview.

For AI endpoint testing, pick AI endpoints in Run a scan. It covers prompt injection, data disclosure, and excessive agency, and publishes to the OWASP LLM Top 10 view.

The attacks use the team's OpenAI key from Settings → AI Provider Keys: your own key in the workspace first, else another member's. The key stays on iKanban's server. aiscan sends promptfoo's OpenAI calls through iKanban, which adds the key and forwards only those calls to OpenAI; usage shows on the key as aiscan. Members of a Pro+ team can run AI scans with the workspace's OpenAI key; the relay only accepts scan traffic (the red team's models, text only, capped replies, 120 calls a minute per member). OPENAI_API_KEY in the shell, when set, is used instead.

A scan run is separate from viewing the findings page. On the Audit Log view, the button on the right is CSV: it exports the filtered rows.

Infrastructure scans: containers, IaC and DAST

The Infrastructure tab lists the scans of how you ship and run the app, and their findings.

• Run a scan has the same targets: Containers & IaC and Web app (DAST), plus API (OpenAPI) and AWS account (next section). An agent runs them as parts D to G of the scan prompt.
• DAST targets: a workspace owner or admin adds the URLs DAST may scan, under DAST targets on the Infrastructure tab. A scan of any other URL is refused, by the command and by the server.
• Controls follow real runs. Container / image scanning, IaC scanning and DAST / runtime scanning read Enforced after a complete run in the last 30 days with no open critical or high finding of that kind, and Advisory when such findings are open. With no run in 30 days they stay Missing. Each shows when it was last checked.
• Trivy or Docker. Without a trivy command, infrascan runs Trivy's official container (aquasec/trivy:0.76.0) when Docker is running. The container sees the repository read-only and the scan folder only. It gets the Docker socket only for an image that exists on your machine alone (built by compose, for example). The report's "ran" line names the Trivy that ran. With neither Trivy nor Docker, the scan reports SKIPPED with both ways to fix it, never a pass.
• Messy layouts are expected. infrascan starts with an inventory of each --path: what it found, what Trivy scanned, and what it could not scan and why. Repeat --path when infrastructure lives in another folder or repository. Images named in docker-compose files are scanned too. Infrastructure written as code (AWS CDK, Pulumi, CDK for Terraform, Vagrant, Ansible, cloud-SDK scripts) is listed as found but not scannable, with the next step (for CDK: npx cdk synth, then rescan).
• A path with no infrastructure-as-code file is recorded as checked, never as a pass: IaC scanning stays Missing.
• Container images file their critical and high findings; medium and low stay in the local scan report. One scan files at most 500 findings per section: the 500 worst, and that run counts as incomplete, so nothing closes. The report says how many were left out.
• Scan files: every scanner keeps its raw output and report encrypted under ~/.ikanban/scans/, outside the repository. See What a scan sends, and what stays on your machine below.
• Every scan can show in Pipelines: add --task KEY (a task such as IKA-123). A scan sent to your runner from Run a scan does this by itself. The stage log gets one line as each step starts and ends, while the scan runs, then the summary at the end. The report itself never goes to the log.
• Click a finding row (or press Enter on it) to open the finding panel: plain words, False positive or Accept risk, and Create fix task.

Where each finding shows, and its OWASP tag

Each finding shows on exactly one tab. OWASP Top 10 lists code findings only (secscan). OWASP LLM Top 10 lists AI findings. Infrastructure lists every container, IaC, web app, API and AWS account finding, inside the control row of the scan that found it:

Open a control to see the evidence lines (last complete run, scope, open counts) and then its findings, worst first: 20 rows, then Show all. A control with no scan behind it has no findings list. A DAST target's N open findings opens its control on that target's open findings, with a chip to clear the filter (kept in the address as ?kind=dast&target=URL).

Each infrastructure finding has a small tag from its own OWASP list:

The tag comes from the server, so the API (owasp_tag on each finding) and the MCP tools return the same one.

API and AWS account scans

Four Infrastructure rows follow these scans: API vulnerability scan, AWS infrastructure audit, Database network isolation and Database security review. Until a complete run in the last 30 days, each reads Not checked yet, never Enforced, with one line naming the Run a scan part that checks it. After a run they read Enforced, or Advisory while open critical or high findings of their scan remain.

• The API description comes from your code. The scan agent reads the backend's routes in the repository and writes an OpenAPI 3 file to .iKanban/scans/openapi.json, which is never committed. Its servers must be the registered URL, or a path such as /api. The scanner refuses a description whose servers, $ref entries or path keys point anywhere else, and pins every request to the registered host.
• Long scans wait in short checks. The API scan and the AWS audit can take more than 10 minutes, and an agent's shell may stop one command after about 10. The agent starts such a scan in the background with its output in .iKanban/scans/NAME.log, then checks it in the foreground every few minutes, and never replies before it ends (on the runner a reply ends the session and the scan with it).
• API scan limits. --max-minutes (default 10; the prompt uses 30): ZAP stops its active scan 2 minutes before it, and dastscan waits 3 minutes more for ZAP's report. A report that arrives late, or after ZAP failed, is filed as an incomplete run: its findings show, but the row stays Not checked yet. --rate N caps the requests per second ZAP sends (default 10 for an active API scan, no limit otherwise, 0 turns it off); lower it when the report shows many 429 answers.
• Requests reach the routes. The agent gives every path parameter an example value, a real id of the test team (team, project, task) or a valid UUID, and lists each route once under the prefix the server serves, so ZAP's requests are not stopped by a 400 or 404.
• The API scan attacks. ZAP's API scan sends attack requests to each route. Scan a dev or test deployment. The production iKanban API (api.i-kanban.com) is refused unless you add --passive. Sign in as a test team: put its key in ZAP_AUTH_HEADER_VALUE (for example Bearer KEY) in your shell. The key reaches ZAP through the container environment only.
• The AWS audit only reads. cloudscan runs Prowler (prowlercloud/prowler:5.44.0) with your own AWS profile. It checks the account with aws sts get-caller-identity first and refuses another account. It passes short-lived credentials into the container by name and never mounts ~/.aws. Use a read-only role (AWS managed policies SecurityAudit and ViewOnlyAccess); the scan warns when the role name has none of ReadOnly, SecurityAudit or ViewOnly.
• What leaves your machine: only findings (check id, resource ARN, region, severity and the fix) and the run's counts. Never the credentials, never Prowler's raw output. A finding's title reads Fails: <check title>, because Prowler's check titles name the passing state; a rescan updates the titles of findings it filed before.
• Database rows: Database network isolation counts the RDS public-access, VPC, snapshot and port 5432 checks; Database security review counts the RDS encryption, backup, deletion-protection, IAM sign-in, upgrade, monitoring, Multi-AZ, engine-version and admin-name checks. A region with no RDS resource is recorded as checked but not complete: both rows stay Not checked yet.
• Where to change a gate: the DAST target list is on the team's Infrastructure tab (owner or admin). The plan features dastScan and cloudScan are Pro+; a lower plan gets a 402 when it publishes, and the scan still keeps its local report.

Read a finding

Select a finding to open its panel. In plain words comes first: what it is, what it means and why it matters. How to fix it gives the one fix, then the scanner's own detail. Where names the file and line, and the header names the repository the scan covered.

For a finding that is not real, such as a sample key in a test, select False positive (code findings) and give the reason. For a real risk you choose to keep, select Accept the risk with the reason. A rescan never reopens either; Reopen undoes it. The scanner (secscan 1.3.0 and later) already skips keys in test code: a Rust #[cfg(test)] module or #[test] function, a Python test_ function, and test, fixture and doc folders.

To work through findings with an agent, use the ikanban-security-triage skill (.iKanban/prompts/security-triage.md for other agents).

Fix a finding with an agent

On iKASecure → All teams, open a finding's menu and select Fix with an agent. Claude, Copilot and Antigravity run on my machine; Claude and Copilot also run on GitHub. For a dependency finding, Antigravity · GitHub is greyed out: Antigravity on GitHub refuses every edit to package.json, lockfiles and Cargo.toml, so it can't upgrade a package. Use Antigravity on my machine, or Claude or Copilot, instead.

While the agent works, the finding reads Agent fixing. When its pull request is open, it reads In review until a person merges it. When the fix task is done, the finding becomes Fixed by itself. Mark fixed and Reopen in the menu change a code or dependency finding by hand; a finding marked as a false positive or an accepted risk keeps that status. Accept the risk works on an open finding of every kind and needs a reason: open the finding (or Accept risk… in its menu), select Accept the risk, and write why. The finding then reads Risk accepted with your reason, leaves the open counts, and a rescan never opens it again. Reopen in the finding undoes it. On an AI finding, Mark false positive also needs a reason.

Cancelling a fix task frees its finding: the finding no longer points to the cancelled task, and Create fix task or Fix with an agent files a new one.

Security-only API keys

A scanner or CI job needs a key, but not a key to the whole workspace. In Settings → API Keys, create the key with Area set to Security only. That key can read and file security findings, scans and fix tasks through the API and MCP, and nothing else. Add Read-only key to stop it from changing anything.

Through MCP, a Security-only key can use these tools:

MCP is the public API. The REST exceptions are the upload routes that the shipped scanners and CI call with a vk_ key, and the route that adds an application:

• POST /api/teams/{id}/security/scan-findings
• POST /api/vulnerabilities/bulk
• POST /api/teams/{id}/security/ai-seed (the AI scanner's findings and run)
• POST /api/teams/{id}/security/applications ({"name": "backend", "display_name": "…"}; 409 when the team already has that name)

Audit log

The audit log is workspace-wide, even though it appears within a team's iKASecure page. It is sorted newest first, supports filtering and search, and retains events for 90 days. Use CSV to export the currently filtered rows. Each finding status a person sets, from a screen or security_set_finding_status, adds a row: security.finding_fixed, security.finding_reopened, security.finding_false_positive or security.finding_accepted, with the source, the finding and the reason. This view is available only to workspace Owners and Admins with the required entitlement.

Related guidance

See Data Security for how configured AI provider keys and notification text are handled. See Members & Roles for team membership and role guidance.