The neutron security-group-list command with filtering by NON-EXISTING tenant-id will create unexpected default security-group, details are shown below:
# neutron security-group-list --tenant-id UNDEFINED
# show neutron database table: securitygroups, you will find a sg entry with project_id: UNDEFINED, which is not existed in keystone.
MariaDB [neutron]> select * from securitygroups;
+----------------------------------+--------------------------------------+---------+------------------+
| project_id | id | name | standard_attr_id |
+----------------------------------+--------------------------------------+---------+------------------+
| XXXXXXX | 457dfd14-68d3-4a89-a987-52a6fab85496 | default | 103 |
| 12345 | 6fd9d319-10e4-4ec4-842d-7c049cf10113 | default | 233 |
| abc | 8666935a-520e-40f3-a92e-150934179535 | default | 223 |
| UNDEFINED | 9c282662-f973-4f7f-9fa3-d5ed6e2ac71f | default | 228 |
+----------------------------------+--------------------------------------+---------+------------------+
# same thing happens to the table securitygrouprules:
MariaDB [neutron]> select * from securitygrouprules WHERE project_id='UNDEFINED';
+------------+--------------------------------------+--------------------------------------+--------------------------------------+-----------+-----------+----------+----------------+----------------+------------------+------------------+
| project_id | id | security_group_id | remote_group_id | direction | ethertype | protocol | port_range_min | port_range_max | remote_ip_prefix | standard_attr_id |
+------------+--------------------------------------+--------------------------------------+--------------------------------------+-----------+-----------+----------+----------------+----------------+------------------+------------------+
| UNDEFINED | 376c6247-41b7-48b1-ae69-dd97062edc8a | 9c282662-f973-4f7f-9fa3-d5ed6e2ac71f | 9c282662-f973-4f7f-9fa3-d5ed6e2ac71f | ingress | IPv6 | NULL | NULL | NULL | NULL | 231 |
| UNDEFINED | 4aab7577-8433-4f62-b156-03ba1c374cb3 | 9c282662-f973-4f7f-9fa3-d5ed6e2ac71f | NULL | egress | IPv4 | NULL | NULL | NULL | NULL | 230 |
| UNDEFINED | 86337a57-1735-4dbb-874f-7cf13a32b4d1 | 9c282662-f973-4f7f-9fa3-d5ed6e2ac71f | 9c282662-f973-4f7f-9fa3-d5ed6e2ac71f | ingress | IPv4 | NULL | NULL | NULL | NULL | 229 |
| UNDEFINED | e7e774a9-ee3c-4dfb-9e77-fa3630751bfc | 9c282662-f973-4f7f-9fa3-d5ed6e2ac71f | NULL | egress | IPv6 | NULL | NULL | NULL | NULL | 232 |
+------------+--------------------------------------+--------------------------------------+--------------------------------------+-----------+-----------+----------+----------------+----------------+------------------+------------------+
4 rows in set (0.00 sec)
Tested under OpenStack Kilo and master
This is a 'known' side effect. Neutron expects that a tenant (or project) UUID is valid. To address this, neutron would be required to interact with keystone in order to assert the validity of the submitted parameter.