The typical method to add restrictions to what is allowed when attempting to authenticate with particular private key, is via the relatively underused "options" field in a ~/.ssh/authorized_keys file on the server - specifically for your use-case would be the ability to configure/restrict from which hosts a particular keypair can be used with the from="pattern-list" option.
For example:
# ~/.ssh/.authorized_keys
from="10.80.0.0/14,192.168.1.2,hbruijns-workstation.internal.example.com" ssh-rsa AAAAB3NzaC1y***...***== hbruijn@serverfault
That for example only allows login with the matching private key only from hbruijns-workstation.internal.example.com, the IP-address 192.168.1.2 and/or any IP-address from the range 10.80.0.0/14.
As a further refinement you can place the ~/.ssh/.authorized_keys under control of the server admin to ensure that your team members don't override that restriction.
As I already commented and you already mentioned as well, that doesn't help you much when your network does not support the prerequisites for implementing a security model that depends on trusted clients and you don't have a reliable method to identify them.:
- you need to have a reliable method to identify your trusted clients.
When your clients do not get assigned a fixed IP and/or hostname this method won't work (but neither will any other).
So the request "to authorise ssh connections to the servers only from the PCs given to each team member" should be declined or countered with a request to for example get the required static IP-address assignments for your team member PC's, or for example a management network where your team members can connect to with VPN.