Problem
If a policy rule in tool_policies references a protocol that is not configured (for example protocol: "git" when only mcp is actually used), AegisFlow starts up silently and the rule never matches.
Users only find out when the rule fails to do what they expected. That is a rough debugging experience.
Acceptance criteria
Files to touch
internal/config/config.go (add a ValidateToolPolicies helper)
cmd/aegisflow/main.go (call the helper after loading config)
internal/config/config_test.go (new tests)
How to test locally
Create a config with a bad protocol:
tool_policies:
rules:
- protocol: "bogus"
tool: "*"
decision: "block"
Run ./bin/aegisflow --config that-config.yaml and check the startup output for the warning line.
Notes
This is pure validation, not enforcement. We do not want to reject the config, just help the user notice the mistake.
Problem
If a policy rule in
tool_policiesreferences a protocol that is not configured (for exampleprotocol: "git"when onlymcpis actually used), AegisFlow starts up silently and the rule never matches.Users only find out when the rule fails to do what they expected. That is a rough debugging experience.
Acceptance criteria
tool_policies.rulesand log a warning if a rule uses a protocol that is not in the known set (mcp,http,shell,sql,git,*)[config] tool policy rule #N references unknown protocol %q, rule will never matchinternal/config/covers the warning pathFiles to touch
internal/config/config.go(add aValidateToolPolicieshelper)cmd/aegisflow/main.go(call the helper after loading config)internal/config/config_test.go(new tests)How to test locally
Create a config with a bad protocol:
Run
./bin/aegisflow --config that-config.yamland check the startup output for the warning line.Notes
This is pure validation, not enforcement. We do not want to reject the config, just help the user notice the mistake.