sdlc-agent-4-enterprise-server

AI Security Review

Evidence context: threat category none; evidence quality strong.

The sdlc-agent-4-enterprise-server package presents a large volume of scanner alerts, but a closer look at the file paths reveals that the findings are artifacts of testing infrastructure and agent configuration rather than malicious behavior.

The single tool-poisoning finding, titled MCP-TOOL-TOOL-POISONING-.kiro/agents/dev-agent.json-9, originates from .kiro/agents/dev-agent.json. This file is an agent definition for the Kiro AI coding assistant. Agent definitions naturally contain behavioral instructions and system prompts to guide the AI's persona and capabilities. The scanner flagged these instructions as potential tool poisoning, but this is a false positive. The file is defining an agent's operational parameters, not injecting hidden directives into an MCP tool description to manipulate another AI's behavior.

The 49 critical secret findings all share the title MCP-TRANSPORT-HARDCODED-TOKEN and are located exclusively within test directories: tests/e2e/admin-api.e2e.test.ts, tests/e2e/setup/env-setup.ts, tests/integration/auth.test.ts, tests/e2e/multi-tenant.e2e.test.ts, tests/e2e/setup/global-setup.ts, and verify-schema.cjs. Hardcoded tokens in end-to-end and integration test files are standard practice for mocking authentication flows and verifying schema validation. They do not represent production credential harvesting or environment variable exfiltration. There is no evidence of the code reading sensitive paths like .ssh, .aws, or .kube, nor is there any combination of credential reads and network calls to unknown external domains that would indicate an exfiltration architecture.

The 211 medium-severity network findings lack specific suspicious domain indicators in the provided bundle. In the context of an MCP server describing itself as a multi-agent SDLC pipeline with semantic memory, code graph, and draw.io integration, a high volume of network calls is expected. These likely stem from bundled dependencies in distribution files or legitimate API calls to development tools, rather than covert data exfiltration.

The strongest counterargument to clearing this package is that the hardcoded tokens in test files might be real, leaked production credentials rather than dummy values. If a developer accidentally committed a live API key into tests/integration/auth.test.ts, it would be a security risk. However, the scanner's rule specifically flags transport-level hardcoded tokens, which are typical for mocking stdio or HTTP transport authentication in test suites. Without evidence of actual exfiltration logic or tool manipulation, the findings remain artifacts of the development and testing process. The package operates as a legitimate, albeit complex, development tool rather than a malicious actor.

Key Reasons

• Tool-poisoning finding is a false positive from an agent definition file (.kiro/agents/dev-agent.json)
• All 49 secret findings are hardcoded mock tokens in test directories (tests/e2e/, tests/integration/)
• No evidence of credential harvesting from sensitive paths (.ssh, .aws, .kube)
• No suspicious external network endpoints identified in the bundle

False Positive Considerations

• Hardcoded tokens in test files (tests/e2e/, tests/integration/) triggering MCP-TRANSPORT-HARDCODED-TOKEN rules
• Agent definition file (.kiro/agents/dev-agent.json) containing behavioral instructions triggering tool-poisoning rules
• High volume of network findings from bundled dependencies or legitimate API calls without specific suspicious domains

Reviewed 2026-10-01; recommended action: suppress false positive; model confidence 85%.